Skip to content

feat(cli): roamcode status — service, reachability, and running build at a glance#75

Open
dchaudhari7177 wants to merge 1 commit into
burakgon:mainfrom
dchaudhari7177:feat/cli-status
Open

feat(cli): roamcode status — service, reachability, and running build at a glance#75
dchaudhari7177 wants to merge 1 commit into
burakgon:mainfrom
dchaudhari7177:feat/cli-status

Conversation

@dchaudhari7177

@dchaudhari7177 dchaudhari7177 commented Jul 10, 2026

Copy link
Copy Markdown

Closes #69

What

New roamcode status subcommand (packages/cli/src/status.ts, lazily imported like install so the serve path stays lean):

  1. Service: reads <dataDir>/service.json via the server's own resolveDataDir (so it sees exactly what roamcode install wrote) and prints Service: <manager> · <label>, or none installed, with a roamcode install hint — and still probes the port in that case.
  2. Reachability: GET http://127.0.0.1:<PORT>/health (PORT env when it's a usable positive integer, else 4280 — PORT=0 means "pick a free port" at serve time, so status falls back to the default) with a 2s AbortSignal.timeout. Exit 0 when reachable, 1 when not, so scripts can roamcode status && ….
  3. Build info (best-effort): /version is token-gated, so when a token is available (ACCESS_TOKEN env wins, else the persisted <dataDir>/token — same precedence as the server) the output becomes running at … (v0.4.2 · abc1234). No token / 401 / timeout quietly degrades to plain running — never contradicting the /health answer already in hand.

args.ts accepts the leading status positional (same pattern as install/uninstall) and the help text gains a line.

Tests

packages/cli/test/status.test.ts follows the existing deps-injection style (injected fetchFn + in-memory readFile, no real network or data dir): not-installed+unreachable→exit 1, installed+up+token→full detail line, no-token→/version never fetched, stale-token 401→plain running, PORT env + ACCESS_TOKEN-beats-file precedence, PORT=0→default 4280, corrupt service.json tolerated. Plus a status parse case in args.test.ts.

Verification

  • pnpm typecheck green; vitest run packages/cli — all 31 status/args/run tests that pass on main still pass plus the 8 new ones (the 4 pre-existing install failures on a Windows checkout — backslash join() paths and chmod-mode asserts — are unchanged and don't occur on Linux CI).
  • Smoke-ran the real CLI: with nothing listening → Service: none installed… / Server: not reachable at http://127.0.0.1:4280, exit 1. Against a stub /health+/version server with ACCESS_TOKEN set → Server: running at http://127.0.0.1:4280 (v0.9.9 · cafe123), exit 0.

… at a glance

'Is it actually running? On which port? Which build?' previously needed
launchctl/systemctl incantations. `roamcode status` now answers directly:

- reads <dataDir>/service.json (via the server's own resolveDataDir) and
  prints the installed service manager + label, or a 'run roamcode install'
  hint when none was ever installed
- probes GET /health on 127.0.0.1:<PORT> (PORT env or 4280) with a ~2s
  timeout and exits 0 when reachable, 1 when not, so scripts can gate on it
- best-effort GET /version (token from ACCESS_TOKEN or <dataDir>/token)
  enriches the output to 'running (v… · <sha>)'; any failure there quietly
  degrades to plain 'running'

Unit tests follow the existing deps-injection style — no real network or
data dir anywhere.

Closes burakgon#69
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CLI: roamcode status — is the service running, where, which build

1 participant