What happened?
With no daemon running (verified: no hunk processes, nothing listening on the default port 47657), hunk session list prints No active Hunk sessions. and exits 0 — byte-identical to the healthy daemon-up-but-zero-sessions case. --json mode is equally ambiguous (same empty result, exit 0).
Scripts and coding agents driving hunk session * therefore can't tell "daemon unreachable / agent sandbox blocked loopback" from "genuinely no sessions". The agent skill already hints at this ('if Hunk is visibly running, localhost may be blocked by the agent sandbox') but there is nothing programmatic to branch on — we hit this in a wrapper that resolves the newest live session via hunk session list --json before attaching an annotation agent.
Related: #406 fixed the daemon-down hang (Windows); the quiet fallback that replaced it is what makes the two states indistinguishable now.
Steps to reproduce
- Ensure no daemon:
pkill -f hunk; confirm with lsof -nP -iTCP:47657 -sTCP:LISTEN (empty).
hunk session list; echo $? -> No active Hunk sessions. / 0- Start any TUI (
hunk diff) in another terminal and quit it so the daemon stays up with zero sessions.
hunk session list; echo $? -> identical output and exit code as step 2.
Expected behavior
A distinguishable signal when the daemon is unreachable — any of: a distinct message on stderr + nonzero exit, a --fail-if-no-daemon flag, or a daemon/status field in the --json output. Exit 0 with the current message would then unambiguously mean "daemon up, zero sessions".
Version
0.17.0 (Homebrew bottle, macOS Tahoe / Darwin 25.5.0)
What happened?
With no daemon running (verified: no hunk processes, nothing listening on the default port 47657),
hunk session listprintsNo active Hunk sessions.and exits 0 — byte-identical to the healthy daemon-up-but-zero-sessions case.--jsonmode is equally ambiguous (same empty result, exit 0).Scripts and coding agents driving
hunk session *therefore can't tell "daemon unreachable / agent sandbox blocked loopback" from "genuinely no sessions". The agent skill already hints at this ('if Hunk is visibly running, localhost may be blocked by the agent sandbox') but there is nothing programmatic to branch on — we hit this in a wrapper that resolves the newest live session viahunk session list --jsonbefore attaching an annotation agent.Related: #406 fixed the daemon-down hang (Windows); the quiet fallback that replaced it is what makes the two states indistinguishable now.
Steps to reproduce
pkill -f hunk; confirm withlsof -nP -iTCP:47657 -sTCP:LISTEN(empty).hunk session list; echo $?->No active Hunk sessions./0hunk diff) in another terminal and quit it so the daemon stays up with zero sessions.hunk session list; echo $?-> identical output and exit code as step 2.Expected behavior
A distinguishable signal when the daemon is unreachable — any of: a distinct message on stderr + nonzero exit, a
--fail-if-no-daemonflag, or adaemon/statusfield in the--jsonoutput. Exit 0 with the current message would then unambiguously mean "daemon up, zero sessions".Version
0.17.0 (Homebrew bottle, macOS Tahoe / Darwin 25.5.0)