> ## Documentation Index
> Fetch the complete documentation index at: https://docs.selftune.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# selftune service

> Manage the persistent authenticated dashboard runtime

`selftune service` installs and controls the same SelfTune CLI binary under the
native user-level OS supervisor. The desktop app and CLI do not maintain
separate background executables.

## Usage

```bash theme={null}
selftune service install
selftune service status --json
selftune service start
selftune service stop
selftune service restart
selftune service uninstall
```

| Platform | Supervisor               |
| -------- | ------------------------ |
| macOS    | LaunchAgent (`launchd`)  |
| Linux    | `systemd --user` service |
| Windows  | Task Scheduler           |

Installation is idempotent. Packaged desktop releases copy their signed,
manifest-verified runtime to a versioned stable application-support path before
registering it; direct CLI installs register the current CLI executable. The
definition records the version, state directory, dashboard assets, and port.
Local bearer credentials remain outside launchd, systemd, and Task Scheduler
definitions. An explicit install first authenticates to and stops the runtime
using the same state directory, then transfers the singleton to the service.

Runtime ownership and supervision are separate. A foreground CLI daemon is
CLI-owned without an OS supervisor, while a persistent service can be owned by
the CLI or desktop installer. The desktop preserves and attaches to registered
services with an equal, newer, or unknown version; it only replaces a service
that has an older valid SelfTune version. A directly started CLI daemon is not
terminated when the desktop app quits. A desktop child orphaned by an app crash
is authenticated and stopped before a later desktop instance replaces it.
That cleanup is bound to the original PID and runtime instance ID, so a delayed
desktop shutdown or Windows task cleanup cannot terminate a successor CLI
daemon. Service start and repair succeed only when the authenticated manifest
identifies a healthy OS-supervised runtime.

## Options

```bash theme={null}
selftune service install \
  [--port 7888] \
  [--config-dir PATH] \
  [--owner cli|desktop] \
  [--boot] \
  [--json]
```

`--boot` applies only to Windows and requires elevation. The normal default is
an owner-scoped service that starts when the user signs in. `--owner` is an
advanced integration option; ordinary CLI usage defaults to `cli`, and the
desktop supplies `desktop` automatically.

## Diagnose and repair

```bash theme={null}
selftune service status --json
selftune daemon status --json
selftune service restart
```

The service status reports OS registration and process state. Daemon status
also probes the authenticated health endpoint from the durable manifest. If a
restart does not repair an outdated executable path after an upgrade, rerun
`selftune service install`.

## Rotate local authentication

```bash theme={null}
selftune daemon rotate-token
selftune service restart
```

The local dashboard token is separate from a Cloud or self-hosted Remote
Library account token. Remote Library tokens use the operating system credential
vault when available.

Use `selftune service uninstall` to remove only the supervisor definition. Use
`selftune uninstall` for a complete teardown, including the Remote Library
credential and local state. Stopping or uninstalling the service preserves an
independently started CLI daemon.

Inspect the existing runtime owner, version, state root, executable, and port
before installing or restarting. Ask before changing the OS supervisor. Verify
both registration and authenticated runtime health. Do not remove local data or
remote credentials as part of `service uninstall`.