Development record
hooks/session-start.sh runs the session-start entrypoint even when hooks/bootstrap.sh failed but a plugin binary is present, then exits with bootstrap's non-zero code: the host shows its empty 'startup hook error' banner and drops the notices the entrypoint just printed, the outcome iss-2608241115201044 fixed for the entrypoint's own exit.
issueopenminoriss-2610161125115941
hooks/session-start.sh runs the session-start entrypoint even when hooks/bootstrap.sh failed but a plugin binary is present, then exits with bootstrap's non-zero code: the host shows its empty 'startup hook error' banner and drops the notices the entrypoint just printed, the outcome iss-2608241115201044 fixed for the entrypoint's own exit.
Frontmatter
| id | iss-2610161125115941 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2610161125115941-hooks-session-start-sh-runs-the.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2608241115201044SessionStart exit-2-as-advisory no longer reaches the user. abcd hook session-start returns exitError{Code: 2} whenever it has notices to print (internal/surface/cli/cli.go:1289), on the documented assumption that a non-zero SessionStart surfaces stderr without blocking. Claude Code v2.1.241 instead renders it as 'SessionStart:startup hook error' followed by a truncated echo of the hooks.json command string; the stderr notice itself never reaches the user. Every session-start notice is therefore an opaque error banner: transcript-capture gaps, staged-drain failures, the remaining-backlog count, binary skew, dogfood staleness, and the version transition. The data-loss-adjacent ones matter most - a user told that a session transcript was not captured now sees only a hook error, with no way to learn what it was.