fix(session): report daemon reachability in session list JSON

[YuriNachos]

Fixes #527

Summary

hunk session list --json now includes a daemon object alongside sessions so callers can distinguish an unreachable daemon from a healthy daemon with zero sessions — both previously printed the byte-identical { "sessions": [] } with exit 0.

• Daemon unreachable: { "sessions": [], "daemon": { "available": false } }
• Daemon reachable: { "sessions": [...], "daemon": { "available": true } }

Text-mode hunk session list output and the exit code are unchanged in both states, and existing JSON consumers that read .sessions keep working (purely additive, non-breaking).

Root cause

In runSessionCommand, the daemon-down list branch returned renderOutput(input.output, { sessions: [] }, …) and the daemon-up list branch returned renderOutput(input.output, { sessions }, …). renderOutput serializes the value object as the JSON body, so both produced { "sessions": … } — the reachability boolean from resolveDaemonAvailability was discarded before it reached the output, collapsing "daemon down" and "daemon up, zero sessions" into the same bytes.

Changes

• src/session/agent/commands.ts — pass daemon: { available } inside the value to renderOutput for the list action in both branches (available: false on the down path, available: true on the up path). No other action is affected; the return type stays string; src/main.tsx, exit codes, and CLI flags are untouched.
• src/session/agent/commands.daemon.test.ts — update the real-probe strict toEqual to the new shape { sessions: [], daemon: { available: false } }.
• src/session/agent/commands.test.ts — add two hook-based regression tests (daemon-unavailable and daemon-available JSON shapes).
• .changeset/session-list-daemon-status.md — hunkdiff / patch changeset.

Test plan

• bun run typecheck
• bun run lint
• bun run format:check
• bun run test:theme-contrast
• bun run test (1940 pass / 0 fail, incl. src/session/agent/commands.test.ts and commands.daemon.test.ts)
• bun run test:tty-smoke
• bun run test:integration (91 pass / 6 fail — the 6 failures are pre-existing TUI/extension tests that reproduce identically on the clean base c4739ef and are caused by the local worktree environment, not this change; the full unit + session suite is green)
• manual: HUNK_MCP_PORT=<free-port> hunk session list --json now emits daemon.available: false with text-mode and exit code unchanged
• macOS arm64 (Bun 1.3.14)
• Linux / Windows (the windows-compat CI job exercises these unit/session tests)

Co-authored-by: Claude noreply@anthropic.com

[greptile-apps]

PR author is not in the allowed authors list.

[vercel]

@YuriNachos is attempting to deploy a commit to the Modem Team on Vercel.

A member of the Team first needs to authorize it.

[YuriNachos]

The failing Vercel check is Authorization required to deploy — an external-contributor PR from a fork can't trigger the modem-labs Vercel preview deploy without team authorization, so it's unrelated to this diff. Both Socket Security checks (Project Report, Pull Request Alerts) pass. The change itself is backend-only (src/session/agent/commands.ts + tests + changeset) and doesn't touch any frontend/deploy path.

[YuriNachos]

Heads-up on the red check here: the failing Vercel job is not caused by this PR — it's the fork-deployment authorization gate, and it fails on every fork PR in this repo.

I enumerated the 8 most recent open PRs and correlated the Vercel conclusion with where the head branch lives:

PR	Vercel	head repo
#693	SUCCESS	modem-dev
#689 (this one)	FAILURE	YuriNachos (fork)
#688	SUCCESS	modem-dev
#686	FAILURE	privatenumber (fork)
#683	SUCCESS	modem-dev
#682	FAILURE	IAMLEIzZ (fork)
#680	SUCCESS	modem-dev
#678	FAILURE	HackAttack (fork)

4/4 fork PRs fail, 4/4 in-repo branches pass — no exceptions. The check's target URL is
vercel.com/git/authorize?..., i.e. it wants a Vercel account authorization that a fork
contributor cannot grant.

The two checks that do evaluate this code — Socket Security: Project Report and
Socket Security: Pull Request Alerts — are both green. Nothing to fix on my side, but shout if
you'd rather I rebase or push the branch somewhere Vercel can deploy from.