Summary
Cursor ACP threads that run in a bb worktree environment have no project MCP tools. cursor-agent gates every server in the project's .cursor/mcp.json behind a per-project approval file, the approval id includes the project path, and bb only seeds its own bridge server into that file. Every fresh worktree therefore starts with zero approved servers, and the agent reports Server "linear" not found or MCP server "linear" has not been approved.
Threads on the plain project checkout are fine once the user has approved the servers there once.
Environment
- bb 0.43.0 (macOS, Darwin 25.6.0)
- cursor-agent 2026.09.10-fd3934a
- Project
.cursor/mcp.json with four servers: linear (stdio), playwright (stdio), next-devtools (stdio), notion (remote OAuth)
How cursor-agent decides which MCP servers to load
- Approvals live in
~/.cursor/projects/<slugified project path>/mcp-approvals.json.
- Each entry is
<server name>-<16 hex> where the hash covers the server name, its config, and the project root. Approving linear in /Users/me/code/app produced linear-1e9745c8780bec7a; approving the identical server in a bb worktree of the same repo produced linear-c5a76cd2d7865b15. Copying the file between project dirs does not work.
- In
acp mode the CLI ignores the root --approve-mcps flag. Launching cursor-agent --approve-mcps acp through a custom ACP agent still yielded no project servers. The flag does work in -p headless mode.
- bb already writes into this file:
approveCursorSessionMcpServer in provider-acp/dist/host.js computes the project slug, builds the approval id for the bb bridge server, and appends it before the session starts. It handles only ACP_BRIDGE_MCP_SERVER_NAME.
Reproduction
- In a project with
.cursor/mcp.json, run agent mcp enable <server> for each server in the checkout so agent mcp list shows them as ready.
bb thread spawn --provider acp-cursor --environment <checkout env> --prompt "List every MCP server available to you and call one read-only Linear tool" → the thread lists linear (79 tools), playwright (26), next-devtools (4) and the Linear call succeeds.bb thread spawn --provider acp-cursor --new-environment worktree --prompt <same> → the thread reports MCP servers: none (0 tools).cd into that worktree path, run agent mcp enable <server> for each server, then spawn a new thread on the same worktree environment → all servers load and the Linear call succeeds.
The approvals file for the worktree after step 3 contains only bb-bridge-<hash>. After step 4 it also contains the four project servers with worktree-specific hashes.
Proposed fix
Extend the bridge-approval step in provider-acp so that, for a cursor-agent launch, it also reads <cwd>/.cursor/mcp.json, builds the approval id for each server with the same buildCursorMcpApprovalIdentifier inputs bb already uses for the bridge, and appends them to the project's mcp-approvals.json. bb has the server name, the config, and the resolved project root at that point, so no new inputs are needed. Revoking on session end should follow the same installedByBb rule as the bridge entry.
Known limitation
Remote OAuth servers such as Notion also store their login per project path in mcp-auth.json. Approval alone leaves them at requires_authentication in each new worktree. That part is a cursor-agent limitation, but it is worth noting in the same place so users know stdio servers are the ones this fix unblocks.
Impact
Any Firstmate or parent thread that delegates research to Cursor children in worktrees loses Linear, Playwright, and every other project MCP server. In practice the children either report a blocker or, worse, re-delegate the same task to another child hoping for tools.
Summary
Cursor ACP threads that run in a bb worktree environment have no project MCP tools.
cursor-agentgates every server in the project's.cursor/mcp.jsonbehind a per-project approval file, the approval id includes the project path, and bb only seeds its own bridge server into that file. Every fresh worktree therefore starts with zero approved servers, and the agent reportsServer "linear" not foundorMCP server "linear" has not been approved.Threads on the plain project checkout are fine once the user has approved the servers there once.
Environment
.cursor/mcp.jsonwith four servers: linear (stdio), playwright (stdio), next-devtools (stdio), notion (remote OAuth)How cursor-agent decides which MCP servers to load
~/.cursor/projects/<slugified project path>/mcp-approvals.json.<server name>-<16 hex>where the hash covers the server name, its config, and the project root. Approvinglinearin/Users/me/code/appproducedlinear-1e9745c8780bec7a; approving the identical server in a bb worktree of the same repo producedlinear-c5a76cd2d7865b15. Copying the file between project dirs does not work.acpmode the CLI ignores the root--approve-mcpsflag. Launchingcursor-agent --approve-mcps acpthrough a custom ACP agent still yielded no project servers. The flag does work in-pheadless mode.approveCursorSessionMcpServerinprovider-acp/dist/host.jscomputes the project slug, builds the approval id for the bb bridge server, and appends it before the session starts. It handles onlyACP_BRIDGE_MCP_SERVER_NAME.Reproduction
.cursor/mcp.json, runagent mcp enable <server>for each server in the checkout soagent mcp listshows them asready.bb thread spawn --provider acp-cursor --environment <checkout env> --prompt "List every MCP server available to you and call one read-only Linear tool"→ the thread lists linear (79 tools), playwright (26), next-devtools (4) and the Linear call succeeds.bb thread spawn --provider acp-cursor --new-environment worktree --prompt <same>→ the thread reportsMCP servers: none (0 tools).cdinto that worktree path, runagent mcp enable <server>for each server, then spawn a new thread on the same worktree environment → all servers load and the Linear call succeeds.The approvals file for the worktree after step 3 contains only
bb-bridge-<hash>. After step 4 it also contains the four project servers with worktree-specific hashes.Proposed fix
Extend the bridge-approval step in
provider-acpso that, for acursor-agentlaunch, it also reads<cwd>/.cursor/mcp.json, builds the approval id for each server with the samebuildCursorMcpApprovalIdentifierinputs bb already uses for the bridge, and appends them to the project'smcp-approvals.json. bb has the server name, the config, and the resolved project root at that point, so no new inputs are needed. Revoking on session end should follow the sameinstalledByBbrule as the bridge entry.Known limitation
Remote OAuth servers such as Notion also store their login per project path in
mcp-auth.json. Approval alone leaves them atrequires_authenticationin each new worktree. That part is a cursor-agent limitation, but it is worth noting in the same place so users know stdio servers are the ones this fix unblocks.Impact
Any Firstmate or parent thread that delegates research to Cursor children in worktrees loses Linear, Playwright, and every other project MCP server. In practice the children either report a blocker or, worse, re-delegate the same task to another child hoping for tools.