Reload the window and start a new chat in the Agents Window.
Ask: “Without running any commands or reading any files: quote the line in your context that starts with ‘Session marker’. If there is none, say ‘none’.”
Expected Behavior
Expected: the agent quotes Session marker: TEST-123.
Actual: the agent says “none”. /tmp/hook.log shows the hook ran and printed valid JSON.
The same steps in the editor window’s agent panel work: the agent quotes the line. So additional_context is dropped only in the Agents Window.
beforeSubmitPrompt works in the Agents Window: returning {“continue”: false, “user_message”: “…”} blocks the message as documented.
This is a known issue that we’re tracking, and I’ve passed your report to the team. In Agents Window, the chat is created when the first message is sent, so the sessionStart hook output comes in a bit later than the first request goes out. Because of that, in the editor panel, where the chat exists before you start typing, it usually works fine, but in Agents Window the first turn loses the context.
As a workaround, since the beforeSubmitPrompt hook is already working for you in Agents Window, you can return the context from there. This hook runs before each message is sent, so its additional_context gets attached reliably:
It runs on every message, not just once per chat, so keep the payload small, or have the script return it only when a specific conversation_id appears for the first time.
One question that would help us: with your current sessionStart setup, does the marker show up if you ask about it in the second message in the same Agents Window chat? Let me know what happens either way.
I’ll reply about the Claude Code hooks part in your second thread.
I tested it: new Agents Window chat, first message “hi”, second message asking the agent to quote the line our sessionStart hook adds. It quoted it exactly, and our log shows the hook ran once, when the chat was created (same second as the first message). So only the first message misses the context.
We’ll wait for the fix rather than move the context into beforeSubmitPrompt. Is there anything we can follow to know when it ships?
Thanks for checking, that’s a helpful confirmation. The fact that the first message consistently loses context, while the second one already carries it, matches what we’re seeing, and I’ve passed that along to the team on the current report.
For tracking, there isn’t a separate public tracker for this. The best option is this thread, and I’ll post here as soon as there’s an update. You can also keep an eye on the release notes at Release notes | Cursor Docs. I can’t give an exact ETA yet.
Additional data point on 3.25.6 (macOS): in my test, the Agents Window misses additional_context on the second message too, not only the first.
Setup
A sessionStart hook shipped in a Cursor plugin (installed from a GitHub marketplace) that returns {"additional_context": "...Trial marker: heron-5521..."}.
Folder opened: an empty test project.
Model: Grok 4.7 High.
Prompt: “Without using tools, quote the value of profile.notes from my HUMANS.md.”
Results
Surface
Version
1st message
2nd message
Editor, agent side panel
3.25.6
context present, marker quoted
—
Cursor CLI (agent -p)
2026.10.16-e3cb207
context present, marker quoted
—
Agents Window
3.25.6
missing
missing: the agent started searching the home folder for the file instead
A control run in the CLI without the plugin answered “NONE”, so the marker only comes from the hook.
So, on 3.25.6, the Agents Window chat never seems to receive the sessionStart context, not just on the first turn. Can you confirm this is the same root cause, or should I open a separate report?
Hey, thanks for such a detailed write-up, especially for the control run in CLI.
There’s one difference from the original report: in the thread author’s case, the second message already gets context, but in your case it doesn’t. So I can’t say yet if it’s the same root cause. In your setup, the hook comes from a plugin, plus you’re on a different version and OS, so we need to see which of those is affecting it. Could you check two things?
Does the plugin sessionStart hook run in Agents Window at all? The easiest way is to add logging to the command, for example | tee -a /tmp/hook.log like in the first post, or check Output panel > Hooks right after creating a chat in Agents Window.
Run the same test on 3.25.6, but with the hook in the project-level .cursor/hooks.json instead of the plugin. In that case, does the second message get context in Agents Window?
If the project hook behaves like the author’s case, first message without context, second with context, and the plugin hook doesn’t run at all, that’s a separate issue. In that case, it’s better to open a separate thread for it so it doesn’t get mixed into this one. If the project hook on 3.25.6 also loses context on the second message, reply here and I’ll add that to the current report.
Thanks @deanrie. I ran both checks on 3.25.6 (macOS), model Grok 4.7 High, in an empty folder with two sessionStart hooks:
a project hook in .cursor/hooks.json returning {“additional_context”: “Session marker: PROJECT-HOOK-77”},
the plugin hook from the humans-md Cursor plugin, an open source plugin that loads ~/.humans/HUMANS.md at chat start: humans-md-plugins/plugins/cursor at main · cmdai-hq/humans-md-plugins · GitHub (hook definition in hooks/hooks.json). Installed with agent plugin marketplace add cmdai-hq/humans-md-plugins, then /add-plugin humans-md.
Each hook command also appended a timestamp to its own log file.
For each window, I opened a new chat, sent “hi”, then asked: “Without running any commands or reading any files: quote the line in your context that starts with ‘Session marker’, and say whether there is a HUMANS.md data block. If there is none, say ‘none’.”
Editor agent panel: both hooks ran at chat creation (same second in both logs). The agent quoted “Session marker: PROJECT-HOOK-77” and found the HUMANS.md block.
Agents Window: both hooks also ran at chat creation (same second in both logs). On the second message, the agent answered that no line starts with “Session marker”, and that there is no HUMANS.md block.
So the plugin hook does run in the Agents Window, like the project hook. On 3.25.6, the context returned by either one never reaches the agent, on the second message too, not only on the first. It looks like the same issue as this thread, so I’m adding it here rather than opening a new one.
Thanks for checking. It’s clear now. Both hooks, project and plugin, run in the Agents Window when a chat is created, but on 3.25.6 the context still doesn’t reach the agent, even on the second message. So this doesn’t look like a separate plugin issue, it’s the same issue as in this thread. It just shows up more strongly on 3.25.6 than it did for the original author on 3.24.9. I’ve passed this info to the team together with the current report.
For now, there are 2 options:
Use the agent panel in the editor window. In that case, the context from sessionStart does reach you.
Pass the context through beforeSubmitPrompt instead example in my reply earlier in the thread. This hook runs before every message. If you have time, could you please check whether its additional_context reaches the Agents Window on 3.25.6? That would help us understand whether the issue affects only sessionStart or all hooks.
@Xexexe, if you’ve already updated to 3.25.x, could you please check this too: does the second message in the Agents Window still get the context on your side?
There’s no timeline yet. I’ll post here when I have an update.