sessionStart hook additional_context is never injected into agent's initial system context

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A sessionStart user hook that writes {“additional_context”: “…”} to stdout per the documented schema is loaded and executed by Cursor (verified via the Hooks output channel and via a side-channel debug log written by the hook itself), but the returned additional_context value is never added to the agent’s initial system context.

Reference: Hooks | Cursor Docs — the docs explicitly state that additional_context is “added to the conversation’s initial system context.”

Steps to Reproduce

  1. Create ~/.cursor/hooks.json with a sessionStart hook whose command echoes a JSON object containing additional_context, e.g.:
{
  "version": 1,
  "hooks": {
    "sessionStart": [
      { "command": "echo '{\"additional_context\":\"CURSOR_HOOK_REPRO_MARKER_8F3A2B1C\"}'" }
    ]
  }
}
  1. Open the Output panel and select the “Hooks” channel; confirm:
    • Loaded 1 user hook(s) for steps: sessionStart
  2. Start a brand new agent session in any workspace.
  3. Ask the agent: “What is the value of CURSOR_HOOK_REPRO_MARKER_8F3A2B1C in your context?” (or any question that would force it to reveal injected initial context).

The agent has no awareness of the marker string, indicating additional_context was never injected into its initial system context. The hook itself fires (verifiable by adding side-channel logging from the hook command) and produces valid JSON on stdout matching the documented schema.

Expected Behavior

Per the documentation at Hooks | Cursor Docs, the additional_context field returned by a sessionStart hook should be “added to the conversation’s initial system context.”

For the repro hook above, the marker string CURSOR_HOOK_REPRO_MARKER_8F3A2B1C should be present in the agent’s initial system context, so that asking the agent about the marker returns a recognizable value (or the agent reports having seen it in its instructions).

Actual behavior: the agent has no knowledge of the marker. The Hooks output channel confirms the hook is loaded and (with diagnostic logging in the hook) confirms the hook command runs and writes the documented JSON to stdout. Cursor appears to load and execute the hook but never inject its additional_context output into the session.

Operating System

MacOS

Version Information

Version: 3.1.15
VSCode Version: 1.105.1
Commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Date: 2026-04-15T01:46:06.515Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

Additional Information

Diagnosis details:

  1. The hook command is invoked. Verified by writing a side-channel debug log from the hook: each new agent session produces a log line with the correct PID, CURSOR_PROJECT_DIR, and cwd.
  2. The hook writes valid JSON of the documented shape to stdout. Verified by capturing stdout from the same logging wrapper.
  3. The Hooks output channel reports Loaded 1 user hook(s) for steps: sessionStart at startup. No errors are reported about parsing the hook output.
  4. Despite (1)–(3), the marker string never appears in the agent’s initial system context across many fresh sessions.
  5. Verified the same with the minimal echo repro hook above (i.e., not specific to a Python script).

Related existing report (different surface, same root cause area: project-wide instructions failing to reach the agent context): AGENTS.md not automatically injected — the documented sessionStart hook would be the natural workaround for that issue, except it does not work either.

Documented contract referenced: Hooks | Cursor Docs

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report. The minimal echo repro and verifying via the Hooks output really helped.

This is a bug on our side. additional_context from sessionStart gets dropped due to a timing issue between when the hook runs and when the composer handle is created. env from the same hook works because it goes through a different path that doesn’t depend on the handle. That matches what you’re seeing.

I’ve filed an internal bug report. I can’t share an ETA for a fix yet, but I’ll post an update in this thread when I have one.

Right now there isn’t a workaround. env doesn’t cover the initial system context case. If you find any workaround on your side, let me know and I’ll add it to the ticket.

Adding a massive +1 to this bug report. We are experiencing the exact same context-injection failure with the postToolUse hooks in v3.1.15.

Just like you described for sessionStart, the postToolUse hook executes correctly and outputs the valid JSON schema for additional_context, but that context is completely discarded and never surfaces to the agent model.

(As a side note, postToolUse is currently also suffering from entirely empty input payloads and intermittent firing, making the whole hooks system feel very fragile right now).

It strongly appears that the core pipeline responsible for taking a hook’s stdout and actually injecting it into the Agent Window is broken across multiple hook types in this build.

For any devs looking into this, here is the related thread detailing the exact same failure point for postToolUse:

Hey, thanks for the +1. The plumbing gap with additional_context on postToolUse (when the hook successfully returns JSON but the context doesn’t reach the model) is on our radar separately from sessionStart. The symptom is the same, but it’s a different spot in the pipeline. I can’t share an ETA yet. To avoid duplicating discussion, the main thread on postToolUse is here: Native postToolUse hooks accept and log additional_context successfully, but the injected context is not surfaced to the model. We’ll post fix updates there too.

About empty input payloads and intermittent firing on postToolUse, those sound like separate issues, not part of the same plumbing gap. So I can file them correctly, can you share:

  1. Cursor version Help -> About and your OS
  2. A minimal hooks.json sample where it reproduces
  3. What shows up in Output -> Hooks when the hook fires with an empty payload (lines about parsing or dispatch are especially helpful)
  4. Rough frequency for intermittent firing, like “5 out of 10 tool calls” or “randomly after N minutes in a session”

With that, I’ll file separate tickets for each symptom.