Different hook behavior in regards to CLI vs MCP usage

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Title: Cursor 3.1.15 — Agents View (new Cursor view) and old Cursor view produce different tool-selection behavior given identical sessionStart hook context

Environment:

  • Cursor version: 3.1.15 (commit 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80, arm64)
  • OS: macOS 25.4.0
  • User-level hooks configured at ~/.cursor/hooks.json and ~/.cursor/hooks/

Summary:
The same sessionStart / subagentStart hook payload produces materially different tool-selection behavior in the Agents View (new Cursor view) vs. the standard Agent Chat view. In Agent Chat, the agent discovers and uses a CLI provided by the hook. In the Agents View, the agent stops at MCP enumeration and reports the capability as unavailable, despite the CLI reference being injected verbatim.

  • The CLI preference (e.g. Slack, Jira, Notion) is based on org-wide knowledge keyspace.

Setup

  • ~/.cursor/hooks.json registers sessionStart and subagentStart both pointing at ./hooks/gns-bootstrap.sh
  • The hook returns additional_context containing:
    XXX --help -v (full CLI reference, including a XXX slack integration with search, channel, thread, convo, etc.)
    XXX whoami (authenticated identity)
    XXX batch-get of server ontology keys
  • No workspace rules are auto-applied. Rules are “agent-requestable” in both views.
  • The XXX CLI resolves to /Users/css/.local/bin/XXX and is authenticated in both environments.

Steps to Reproduce

Reproduction

  1. Open an Agent Chat session (the older/standard view). Ask: “How many thread roots have been posted in (Slack channel) since 2026-04-19 00:00?”
  • Observed: Agent reads the hook-provided XXX --help, discovers Slack channel lookup and Slack channel threads, runs them, returns the correct count.
  1. Open an Agents View session (same account, same hooks, same CLI). Ask the same question.
  • Observed: Agent enumerates MCP servers (none expose Slack), then reports “no Slack integration available” and stops. Does not reach for XXX.

Expected Behavior

User-side verification performed

  • Confirmed the hook fires in both views and returns identical 311,610-byte additional_context JSON.
  • Confirmed via the Agent Chat agent’s own self-report: “At the start of this turn, no workspace rules were pre-loaded into my context… The relevant reference material that was auto-attached came from session hooks, not rules.”
  • So the input to the model should be equivalent — yet tool-selection behavior diverges.
  • Expected Identical hook payloads should produce consistent tool-selection priorities across views. The agent should discover and prefer the CLI whose full reference was just injected.

Actual: The Agents View appears to front-load or weight MCP-server enumeration over additional_context from sessionStart hooks, relative to the Agent Chat view.

Hypotheses (not verified from the client side)

  • Different base system prompts between the two views
  • Different tool-list presentation / ordering to the model
  • Different priority or position given to sessionStart additional_context relative to MCP tool declarations
  • Different default model or tool-use posture
  • None of these are inspectable from outside Cursor’s internals.

Impact sessionStart hooks are a primary mechanism for injecting organization-specific CLI knowledge (internal APIs, auth flows, custom tooling) into agent sessions. If the Agents View materially deprioritizes that context compared to Agent Chat, the hook mechanism is unreliable there for any team depending on this pattern.

Operating System

MacOS

Version Information

Cursor 3.1.15

For AI issues: which model did you use?

Opus 4.17 Max

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Notice “Cursor is unusable” can be a bit of an overstatement, but it’s because it’s a serious detriment to work on the new Agents View.

7

Hey, thanks for the detailed analysis. The comparison between Agent Chat and Agents View is a really useful data point.

This is a confirmed bug that affects sessionStart hook additional_context injection.

This was also reported in this thread, where our team confirmed the root cause and has filed an internal bug. No ETA on a fix yet, but the timing angle from your report (showing it’s worse in one view than the other) will help scope the fix.

Unfortunately, there’s no workaround right now. The env field from the same hook works because it goes through a separate storage path, but it doesn’t cover the additional_context use case. If any of your injected content is fairly static, duplicating it into a .cursor/rules file is a partial fallback, though I know that doesn’t cover your dynamic CLI reference setup.

I’ll update this thread when the fix ships.

8

Thanks Mohit! Admittedly, I did not browse through the previous report before filing this one. Hope it didn’t generate too much extra work on your side. Looking forward to the fix, and to return using the Agents View. Have a good one!