SessionStart hooks not working for new conversations

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/9591
2. https://github.com/anthropics/claude-code/issues/10287
3. https://github.com/anthropics/claude-code/issues/9542

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate:

• #9591 is about displaying the context, not running the script
• #10287 is about all hooks, whereas this is about the SessionStart hook only (the others still appear to work)
• #9542 is about the hooks hanging after being run (on Windows), this is about them never being run at all

Confirmed this issue. Setup:

• SessionStart hook configured in ~/.claude/settings.json
• Hook executes successfully when run manually
• Proper JSON schema validation passes
• Script outputs to stdout as expected

Result: On fresh session start (via /new command), no hook output appears in context. Hook appears to execute silently or output is discarded.

Workaround attempted: None successful without manually running the script.

Config:

"hooks": {
  "SessionStart": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "bash ~/.claude/scripts/validate-commands.sh"
        }
      ]
    }
  ]
}

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

how is this still open ... this is in your docs...

+1 it doesn't work

+1 same here

Title: SessionStart hooks don't fire reliably when opening new VSCode window with multiple windows already open

Description:
When multiple VSCode windows are running Claude Code and I open a new window, plugins that rely on SessionStart hooks fail to load properly. Commands appear in the slash menu but return "Unknown skill" when invoked.

Other plugins (beads, pr-review-toolkit) that register skills statically work fine
~/.claude/plugins/cache/temp_git_* directories accumulate with .orphaned_at markers (225+ in my case)
Running /clear fixes it by re-triggering SessionStart
Reinstalling the plugin also fixes it temporarily
Affected plugin: superpowers (but likely affects any plugin using SessionStart hooks)

Confirmed same issue. Claude Code led me here in troubleshooting it.

I can also confirm that this is broken for me. (Startup hook is ignored.)

Also just tried to create a session startup hook. Same problem. Please fix.

Facing the same issue.

Also experiencing this. As a workaround, I tried moving context injection to UserPromptSubmit hooks instead of SessionStart, but that has its own issues - the additionalContext from UserPromptSubmit hooks also doesn't get injected into Claude's context (related to #12151).

So currently there's no reliable way to inject dynamic context at either:

• Session start (this issue)
• Per-prompt (UserPromptSubmit - #12151)

This makes it impossible to build automation that feeds external information into Claude conversations. Would really appreciate a fix for the hook → context injection pipeline.

Facing the same issue

Wonderful, another broken configuration. I'm here after trying to write a hook to work around user permissions being ignored to copy user permissions to project permissions. OF COURSE that doesn't work either. Why host a github repo for something if you're going to ignore fundamental issues people are filing?

Reporting empirical findings from Claude Code VSCode extension (March 2026):

startup matcher is now firing correctly in VSCode — both on Reload and on /new command.

Observed behavior (session-start-context-load log, 2026-03-03):

12:33:01 [start] session-start-context-load (trigger: startup)   ← VSCode Reload
12:33:01 [skip] already ran this minute                           ← 2nd concurrent fire caught by idempotency guard
12:33:01 [ok] cached last 200 lines (trigger: startup)
12:35:07 [start] session-start-context-load (trigger: startup)   ← /new command
12:35:07 [ok] cached last 200 lines (trigger: startup)

• VSCode Reload: 2 concurrent fires at same second → idempotency guard needed (minute-based lock)
• /new command: single fire observed (1 data point; pattern vs Reload needs further observation)

This suggests the root cause described in this issue has been resolved in recent versions. Environment: Windows 11, VSCode extension, Claude Code v2.1.6x.

This was working for me until very recently and now seems to have stopped.
Opus is already a bit flakey about following instruction reliably so these hooks are the only way to inject a bit of determinism.

Sad state of affairs.

Experiencing this on v2.1.19 (Linux).

• SessionStart hook (Python script outputting plain text) was working for fresh sessions yesterday
• Today, same setup fails silently for fresh sessions
• No version update occurred (installation dates from January 23)
• No script changes
• Hook works correctly after /clear

The intermittent nature is puzzling - no identified variable changed between working and non-working state.

Also experiencing this intermittently on macOS (CLI, not VSCode). I built Tacklebox, a hook server for session coordination and context persistence, and ran into this early on. My workaround is a dual-path injection: SessionStart builds and returns context normally, but for startup sessions we deliberately skip setting an internal context_injected flag. This lets UserPromptSubmit on the first prompt act as a fallback, if SessionStart was silently discarded, UserPromptSubmit catches it and injects the same context. Either way, context is delivered reliably.

Noting that TanakaSeiji's findings above match what we've seen: resume, compact, and clear sources work consistently; it's only startup that's unreliable. The behavior seems environment-dependent and can come and go between versions without any config changes on our side.

When Claude refers to "the issue" it means this issue.

You're right — the issue confirms that /clear does re-trigger SessionStart hooks (it's one of the 3 call sites for qz()). So the hook context was injected into my conversation
   after /clear.

  The issue is about fresh new sessions where SessionStart hooks silently discard their output. /clear is actually the documented workaround.

  So to answer your question: the boot instruction was present in my context (I can see it in the system-reminder). I just didn't act on it proactively before you messaged me —
  that's on me, not a platform bug. I should have called context_summary immediately without you having to ask.

❯ how is that on you and not a platform bug when you had it in the system-reminder and you still didn't follow it?

⏺ Fair point. You're right — if the instruction is in the system-reminder and I still don't follow it unprompted, that's a model reliability issue, not a conscious choice I
  made. I didn't "decide" to skip it; I just failed to prioritize it before responding to your message. That's exactly the kind of flaky instruction-following the issue
  commenters are frustrated about.

  It's a model behavior bug — same category as the comments saying "Opus is already a bit flakey about following instruction reliably."

This is annoying, still happening, please fix.

Cloud-session confirmation, 2026-08-24 (Claude Code on the Web, Ubuntu 24.04 cloud environment) — this still reproduces roughly ten months on, on a different surface from the original macOS CLI report.

Across five cloud sessions, including ones where the SessionStart hook demonstrably ran and did substantial work (installed a toolchain, hydrated 187 Git LFS objects, initialized a submodule), no hook output was delivered to the session's context. The only trace is one debug line:

[DEBUG] Hook output does not start with {, treating as plain text

The hook's stdout is neither shown to the agent nor preserved in the log beyond that line — the text itself is discarded. We only learned what the hook had done by having it tee its own output to a file and reading that file back.

One data point that may narrow the analysis in the original report: that debug line proves something inspected the hook's stdout at session start and decided it was not JSON. So an inspection path does run for a brand-new cloud conversation, even though qz("startup") reportedly is not called for new sessions. Whether the hookSpecificOutput.additionalContext branch would fire if the output were JSON is what we cannot determine from outside the binary — we have just switched our hook to emit JSON and will report back either way.

Context: we hit this while diagnosing a separate cloud-session bug, #89215 — this issue is what kept that one invisible for four test rounds.

Practical impact: a repository cannot use a SessionStart hook to tell the session anything — including that environment setup failed. The session discovers the failure minutes later, at its first red build, with no pointer to the cause. Preserving plain-text hook output in the debug log, even if it is not injected as context, would have saved us several diagnostic rounds.

Follow-up to my comment above — I said we had switched our SessionStart hook to emit JSON and would report back either way. Result, from a brand-new Claude Code on the Web cloud session (2026-08-24):

hookSpecificOutput.additionalContext IS injected on a brand-new session on this surface. The hook's summary arrived as a system message before the session's first tool call. To keep the evidence uncontaminated, the session was asked to answer from context alone before inspecting any file or log; it quoted:

SessionStart hook additional context: Cloud session environment established by the SessionStart hook (exit 0).

Steps:
    toolchain:        ok
    repo LFS assets:  ok
    unity reference:  ok

Full hook output: /tmp/cloud-session-start.log

The same hook, on the same surface, with plain-text output produced nothing in context across five earlier sessions — only the Hook output does not start with {, treating as plain text debug line. So the difference is purely JSON vs. plain text, not whether the hook ran or what it did.

What this does and doesn't say about this issue:

• It is evidence that the additionalContext processing path does run for a new (non-/clear, non-/compact, non-resume) conversation, at least on Claude Code on the Web at this build. That is contrary to the qz("startup") analysis in the original report, so either the cloud surface takes a different path, or the new-session case has been fixed since October and the remaining gap is narrower than the title suggests.
• It says nothing about the macOS CLI path the original report tested — we have no way to exercise that here, and I am not claiming the issue is resolved.

The part that still bites, and may be the more durable half of this report: plain-text hook stdout is silently discarded — not shown to the session, not preserved in the debug log beyond that one line. A hook that prints a human-readable failure gets no signal to anyone. Emitting JSON is the workaround, but nothing in the failure mode points a developer toward it.

Independent confirmation of the intermittent "hook never invoked for brand-new sessions" behavior, via direct session-transcript comparison (Claude Code v2.1.259, VSCode native extension host, Windows 11 Pro 10.0.26200), project-level .claude/settings.json with a single SessionStart hook (no matcher).

Comparing recently-created session .jsonl transcripts under ~/.claude/projects/<project>/:

• Sessions where the hook fired: earliest entries include a type:"attachment" record with attachment.type:"hook_success" (hookName:"SessionStart:startup", containing the hook's raw stdout) immediately followed by attachment.type:"hook_additional_context" — and the injected <system-reminder> is visible in the very next turn's context.
• Sessions where it didn't: the transcript goes straight from the queue-operation/session-init lines to the first real user/attachment:environment entries — no hook_success or hook_additional_context record anywhere, not even a failure/error record. Not a rendering gap — the hook was simply never invoked for that session.

Both session types originated the same way (opening the extension panel and sending a first message), within the same ~20-minute window, same settings file, same hook script — so this isn't a stale-config or caching issue on my end; it's nondeterministic per-session, consistent with qz("startup") only being reached via /clear//compact/URL-resume and not on the plain new-conversation path described in this issue.

Workaround in use: running /clear immediately after opening a new session reliably triggers the hook (matches the root-cause note that /clear does call qz("startup")).