feat: add startup launch support (#1421)

Add launch-at-startup support across the Electron desktop app and the web CLI.

Electron now supports macOS launch-at-login through the native login item API. Login launches start OpenChamber in the background without opening a window, while Dock activation, deep links, and second-instance launches still open or focus the normal app window. The desktop Settings UI now exposes a localized launch-at-login toggle in Desktop Network Access.

The web CLI now includes `openchamber startup status|enable|disable`, backed by native user services:
- macOS: launchd LaunchAgent
- Linux: systemd --user service
- Windows: Task Scheduler

Startup services run `openchamber serve --foreground` so the OS service manager owns process lifetime and restarts. Foreground service updates now defer restarts to the service manager instead of spawning duplicate CLI restarts.

Startup services snapshot useful environment variables by default so provider tokens, PATH, SSH agent settings, and OpenCode configuration survive login/reboot starts. The snapshot avoids shell/session-only state, uses systemd-compatible env quoting on Linux, and avoids unused env artifacts on macOS.

Also adds localized docs for startup services and environment variables.
This commit is contained in:
Bohdan Triapitsyn
2026-05-26 01:36:11 +03:00
committed by GitHub
parent e97bf0d9dc
commit 2014303bc0
30 changed files with 1854 additions and 30 deletions
@@ -44,6 +44,33 @@ openchamber stop
`openchamber` on its own starts the server in the background. Add `--foreground` to keep it attached to your terminal.
## Start OpenChamber at login
Use `startup enable` to install a native user service. OpenChamber uses `launchd` on macOS, `systemd --user` on Linux, and Task Scheduler on Windows.
```bash
openchamber startup enable
openchamber startup status
openchamber startup disable
```
To protect the UI, set the password when enabling the service:
```bash
OPENCHAMBER_UI_PASSWORD='secret' openchamber startup enable
```
`startup enable` snapshots your current environment into the service so it behaves more like starting `openchamber` from the same shell. This keeps provider tokens, `PATH`, SSH agent settings, and other CLI auth/config variables available. Use `--no-env-snapshot` if you want a minimal service environment.
You can still manage tunnels independently for that running service:
```bash
openchamber tunnel start --port 3000
openchamber tunnel stop --port 3000
```
Stopping the tunnel does not restart the service or the app.
## "OpenCode is restarting"
While the server is starting or restarting, OpenChamber shows an "OpenCode is restarting" state and pauses requests until it's ready. This is normal right after launch or a restart. If it never clears, see [OpenCode connection](/troubleshooting/opencode-connection/).