# sessionStart hook additional\_context is never injected into agent's initial system context

**URL:** <https://forum.cursor.com/t/sessionstart-hook-additional-context-is-never-injected-into-agents-initial-system-context/158452>\
**Category:** Bug Reports\
**Tags:** context, hooks\
**Created:** [April 19, 2026, 5:55pm UTC](https://forum.cursor.com/t/sessionstart-hook-additional-context-is-never-injected-into-agents-initial-system-context/158452 "2026-04-19T17:55:26Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dmwyatt](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/dmwyatt/32/14600_2.png) [@dmwyatt](https://forum.cursor.com/u/dmwyatt)\
**Post date:** [April 19, 2026, 5:55pm UTC](https://forum.cursor.com/t/sessionstart-hook-additional-context-is-never-injected-into-agents-initial-system-context/158452/1 "2026-04-19T17:55:26Z")

</div>

### 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](https://cursor.com/docs/hooks#sessionstart) — 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.:

```json
{
  "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](https://cursor.com/docs/hooks#sessionstart), 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](https://forum.cursor.com/t/agents-md-not-automatically-injected/158448) — the documented sessionStart hook would be the natural workaround for that issue, except it does not work either.

Documented contract referenced: [Hooks | Cursor Docs](https://cursor.com/docs/hooks#sessionstart)

### Does this stop you from using Cursor

No - Cursor works, but with this issue

---

<div class="post-metadata">

**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\
**Post date:** [April 20, 2026, 3:59am UTC](https://forum.cursor.com/t/sessionstart-hook-additional-context-is-never-injected-into-agents-initial-system-context/158452/5 "2026-04-20T03:59:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Bogdan\_Parhomenko](https://avatars.discourse-cdn.com/v4/letter/b/ecccb3/32.png) [@Bogdan\_Parhomenko](https://forum.cursor.com/u/Bogdan_Parhomenko)\
**Post date:** [April 29, 2026, 8:50am UTC](https://forum.cursor.com/t/sessionstart-hook-additional-context-is-never-injected-into-agents-initial-system-context/158452/8 "2026-04-29T08:50:07Z")

</div>

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`:

> [@Native postToolUse hooks accept and log additional\_context successfully, but the injected context is not surfaced to the model](https://forum.cursor.com/t/native-posttooluse-hooks-accept-and-log-additional-context-successfully-but-the-injected-context-is-not-surfaced-to-the-model/155689/11):
>
> Adding data points on Cursor 3.1.15 (macOS, 2026-04-21). The postToolUse input side also looks unpopulated, on the same path where the response is discarded — so even fixing the output plumbing wouldn’t be sufficient on its own. Hook script logs process.argv, CURSOR\_\* env vars, and stdin length on every invocation. Representative entries: [2026-04-21T21:53:59.071Z] spawn pid=25047 argv=[] env= [2026-04-21T21:53:59.077Z] stdin-end bytes=0 [2026-04-21T21:55:37.036Z] spawn pid=26394 argv=[] env…

---

<div class="post-metadata">

**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\
**Post date:** [May 3, 2026, 2:21pm UTC](https://forum.cursor.com/t/sessionstart-hook-additional-context-is-never-injected-into-agents-initial-system-context/158452/9 "2026-05-03T14:21:23Z")

</div>

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](https://forum.cursor.com/t/native-posttooluse-hooks-accept-and-log-additional-context-successfully-but-the-injected-context-is-not-surfaced-to-the-model/155689). 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.

---

<div class="post-metadata">

**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\
**Post date:** [May 25, 2026, 2:22pm UTC](https://forum.cursor.com/t/sessionstart-hook-additional-context-is-never-injected-into-agents-initial-system-context/158452/10 "2026-05-25T14:22:20Z")

</div>

Closed on May 25, 2026, 2:22pm UTC

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.
