Silently skip hook-event when Crow app is not running

[dhilgaertner]

Summary

• crow hook-event now silently exits 0 when the Crow app isn't running, instead of failing with "Socket connection failed: Connection refused".
• Catch is scoped to SocketError.connectionFailed inside HookEventCmd only — other CLI commands (new-session, set-status, etc.) still fail loudly when the socket is unavailable, since those are user-initiated.
• Other socket errors (timeout, write/read failures) and JSON-RPC errors continue to propagate so genuine misbehavior stays visible.

Closes #227

Test plan

• make build succeeds.
• swift test --package-path Packages/CrowCLI — 35 tests pass, including new forwardHookEventSilentWhenAppNotRunning.
• Repro: echo '{}' | CROW_SOCKET=/tmp/missing.sock .build/debug/crow hook-event --session $(uuidgen) --event Stop → no output, exit 0.
• Sanity: CROW_SOCKET=/tmp/missing.sock .build/debug/crow list-sessions still prints "Socket connection failed: …" and exits 1.
• Happy path with live app: echo '{...}' | .build/debug/crow hook-event --session <real-uuid> --event Stop → exit 0, event reaches the app.

🤖 Generated with Claude Code

[dgershman]

Code & Security Review

Critical Issues

None.

Security Review

Strengths:

• Error suppression is scoped strictly to SocketError.connectionFailed within forwardHookEvent only — other CLI commands retain their fail-loud behavior for user-initiated operations.
• No new stdin/stdout paths that could leak data; hook payload parsing already existed and the security posture is unchanged.
• The CROW_SOCKET env-var override is existing behavior (legacy support) — not introduced here.

Concerns:

• None identified. The fire-and-forget semantics are appropriate for hook events where the app being absent is a normal condition, not a security boundary.

Code Quality

• Clean extraction: the forwardHookEvent function has a single responsibility and is independently testable.
• The catch SocketError.connectionFailed pattern correctly matches all associated errno values (both ECONNREFUSED and ENOENT), covering both "app not running" and "socket file absent" scenarios.
• Documentation accurately describes the contract (which errors propagate vs. which are swallowed).
• Test uses setenv/unsetenv which modifies process-global state — acceptable here given test speed, but worth noting for future test growth. A defer { unsetenv(...) } correctly restores state.
• All 6 HookEvent tests pass; build is clean with no warnings in the changed files.

Summary Table

Priority	Issue
Green	Consider: if concurrent Swift Testing adoption grows, the setenv-based test could benefit from process isolation, but not blocking today

Recommendation: Approve — well-scoped fix for #227 with appropriate error handling granularity and good test coverage.

[dgershman]

Code & Security Review

Critical Issues

None.

Security Review

Strengths:

• Error handling is scoped narrowly to SocketError.connectionFailed inside forwardHookEvent only — other CLI commands continue to fail loudly when the app is unavailable, preserving the correct behavior for user-initiated operations.
• No new attack surface: no new inputs, no new IPC methods, no privilege changes.
• The CROW_SOCKET env var override in the test is properly cleaned up via defer { unsetenv(...) }.

Concerns:

• None identified. The change correctly distinguishes between expected (app not running → connection failed) and unexpected (timeouts, write/read failures, JSON-RPC errors) socket conditions.

Code Quality

• Clean extraction: The RPC logic was pulled out of HookEventCmd.run() into a standalone forwardHookEvent() function, making it independently testable — good design.
• Catch pattern correctness: catch SocketError.connectionFailed matches all connectionFailed(Int32) variants regardless of errno, which is the right behavior — both ECONNREFUSED (app not listening) and ENOENT (socket file absent) should be silently swallowed.
• Test coverage: forwardHookEventSilentWhenAppNotRunning is a clean regression test — points at a non-existent socket via CROW_SOCKET, verifies the function completes without throwing.
• Doc comment on forwardHookEvent clearly explains the rationale and the error taxonomy (which errors propagate vs. which are swallowed).

Summary Table

Priority	Issue
✅ Green	Consider whether SocketError.createFailed should also be caught — it would fire if the OS can't allocate a socket fd, which is unlikely but also not an app-connectivity issue. Current behavior (letting it propagate) is defensible since it signals a system-level problem.

Recommendation: Approve — this is a well-scoped, well-tested fix for a real usability issue (#227). The error handling taxonomy is correct and the blast radius is minimal.