Summary
When no session-broker daemon is listening on 127.0.0.1:47657, every hunk session *
command (e.g. hunk session list) blocks forever instead of failing fast. There's no
error, no timeout — the command just hangs. This is especially easy to hit on Windows,
where a TUI window doesn't reliably auto-spawn the daemon.
Impact
- Agent/CLI integrations (including the bundled
hunk-review skill) hang with no signal.
An agent can't tell "daemon down" from "still working," so it stalls or gets killed.
- The failure mode is silent:
hunk --version works, the TUI looks fine, but
hunk session list never returns — making it hard to diagnose.
Repro
- Ensure no
hunk daemon serve is running (nothing on 127.0.0.1:47657).
- Run
hunk session list.
- It hangs indefinitely. (Only an external
timeout kills it.)
Starting hunk daemon serve first makes the same command return instantly.
Root cause
The session client connects to the broker port with no connect/read timeout. If the
daemon is absent (or accepts the socket but never completes a response), the client waits
forever. The CLI and daemon are otherwise healthy — it's purely a missing-timeout +
missing-daemon interaction.
Contributing factor on Windows: the TUI does not always start the daemon, so users land
in the "no daemon" state without realizing it.
Suggested fixes (in priority order)
- Fail fast. Give
hunk session * a short connect/response timeout. On failure, exit
non-zero with an actionable message, e.g. No Hunk daemon on 127.0.0.1:47657 — run "hunk daemon serve" or open a Hunk window.
- Auto-start / clear guidance. Either have
hunk session * spawn the daemon on demand,
or ensure the TUI reliably starts it on launch (notably on Windows).
- Docs. Note the daemon dependency and a preflight pattern in the bundled
hunk-review skill so agents guard their calls.
Environment
- Hunk (hunkdiff) v0.15.0, npm global install
- Windows 11, Git Bash (MSYS2), tmux
- Daemon: default
127.0.0.1:47657, IPv4-only bind (minor: tools resolving localhost
to ::1 first won't reach it)
Summary
When no session-broker daemon is listening on
127.0.0.1:47657, everyhunk session *command (e.g.
hunk session list) blocks forever instead of failing fast. There's noerror, no timeout — the command just hangs. This is especially easy to hit on Windows,
where a TUI window doesn't reliably auto-spawn the daemon.
Impact
hunk-reviewskill) hang with no signal.An agent can't tell "daemon down" from "still working," so it stalls or gets killed.
hunk --versionworks, the TUI looks fine, buthunk session listnever returns — making it hard to diagnose.Repro
hunk daemon serveis running (nothing on127.0.0.1:47657).hunk session list.timeoutkills it.)Starting
hunk daemon servefirst makes the same command return instantly.Root cause
The session client connects to the broker port with no connect/read timeout. If the
daemon is absent (or accepts the socket but never completes a response), the client waits
forever. The CLI and daemon are otherwise healthy — it's purely a missing-timeout +
missing-daemon interaction.
Contributing factor on Windows: the TUI does not always start the daemon, so users land
in the "no daemon" state without realizing it.
Suggested fixes (in priority order)
hunk session *a short connect/response timeout. On failure, exitnon-zero with an actionable message, e.g.
No Hunk daemon on 127.0.0.1:47657 — run "hunk daemon serve" or open a Hunk window.hunk session *spawn the daemon on demand,or ensure the TUI reliably starts it on launch (notably on Windows).
hunk-reviewskill so agents guard their calls.Environment
127.0.0.1:47657, IPv4-only bind (minor: tools resolvinglocalhostto
::1first won't reach it)