fix(cursor): mcp.json servers using ${workspaceFolder} now start#24505

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This fixes Cursor MCP workspace-variable handling, but it adds substantial runtime logic to parse configuration files, resolve project roots and placeholders, honor disabled servers, and inject MCP processes into agent startup. The behavior is tested and component-local, yet the new configuration-loading path warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Review in Change Stack →

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 05c0ed7
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: bee05d51-7f3f-4d5f-816e-ab98af0741f2

External image Commits

Reviewing files that changed from the base of the PR and between 4ea0d8d161042c3c4e38b2590012e6d4e822152d and 1b60d28cb686f9adac8f3d3efbe4ef21ec2f99de.

External image Files ignored due to path filters: 1

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

External image Files selected for processing: 3

• packages/provider-cursor/src/server/adapter.test.ts
• packages/provider-cursor/src/server/adapter.ts
• packages/provider-cursor/src/server/workspaceMcpServers.ts

Limit details: You’ve used all 10 included reviews currently available.

@only21mil, thanks for reproducing the unresolved workspace variables and using agent-level overrides while preserving project precedence and disabled servers. i kept your commits, merged current main, and pushed the scoped follow-up to this branch.

• overrides now cover stdio commands only. http/sse stays with the sdk so tls settings and existing oauth identity are preserved.
• root discovery uses the sdk's git rev-parse --show-toplevel behavior. state lookup uses the host environment, matching the in-process sdk rather than provider overrides.
• disabled state uses strict json and fails startup on malformed/unreadable content. the regression fixture now initializes a real git repository.
• the loader is smaller; no ui changes.

verification: reproduced the original test failing on current main (expected undefined), and the new provider-environment regression failing on the original implementation (disabled off was injected). blacksmith vp run check:changed passed format, lint, knip, typecheck of 34 packages, and 19 adapter tests. all 11 CursorReplayFixtures.integration.test.ts tests passed.

unverified and required before merge: authenticated cursor integration. this vm reports logged-out; an actual sdk send with composer-2.5 returned [unknown] Invalid User API Key. please verify the reported .cursor/mcp.json command through an authenticated t3 cursor thread, including disabled-server behavior. maintainer approval remains required. windows was not exercised.

known sdk limit for @only21mil: the sdk still attempts its unresolved file copy, so its load warning can remain. http/sse workspace-variable expansion is deliberately left outside this stdio fix.

ci: all 27 checks passed on 89a2e13f442efdb7914ee3e00a1bee097cabe50d. the original .git probe review concern is superseded by using git itself. two independent follow-up code reviews found no additional semantic blockers; their captured-service/typecheck findings were corrected and verified by the passing checks. coderabbit's automatic review was rate-limited, so no fresh bot approval is claimed. no labels changed, and this pr remains open for maria's review.

Verified in a real dev environment

checked exact head 89a2e13f442efdb7914ee3e00a1bee097cabe50d on this linux boat vm. installed dependencies and ran vp run dev first on github/main (07f7f976097b56450364fe136aac9253f4f7d8e1) in /home/user/main, then on the pr head in /home/user/t3code, stopping main before starting the pr. both used isolated data and no seeded/demo data. drove the actual web app with repository playwright and /usr/bin/google-chrome.

added the real repository through the app. real codex gpt-6.1-sol turns completed on both versions, running git and returning the repository root and head. on the pr, a follow-up turn after the cursor failure also completed and returned the actual git status. this verifies basic client/server/provider execution and thread continuation, not the cursor fix.

configured the real @modelcontextprotocol/server-filesystem server in .cursor/mcp.json, once with ${workspaceFolder} in the script path and once with an absolute path. cursor provider setup on both versions reports Not authenticated. an actual t3 thread start --provider cursor --model composer-2.5 --wait request against the pr dev server failed with Cursor Agent SDK open failed. the server cause was ProviderSetupError: Sign in with Cursor or add CURSOR_API_KEY in provider settings.

existing blacksmith checks passed this turn: 19 cursor adapter tests and all 11 cursor replay integration tests. those checks use their existing test doubles/replays and do not establish authenticated cursor integration. the pr has 27 successful ci checks, but currently conflicts with main. no source changes, commits, pushes, label changes, or merge actions.

main: cursor authentication blocker

main cursor provider reports not authenticated

pr: same cursor authentication blocker

pr cursor provider reports not authenticated

pr: real sol turn and follow-up after the cursor failure

real sol turns complete on the pr head

recording of the real sol turn, with loading frames trimmed; uploaded playback and seeking checked

real gpt-6.1-sol turn through the pr web client

git.cafe currently renders these external media embeds as links. the uploaded video was checked in t3's player, including playback and seeking.

short runtime transcript

Not verified

the changed cursor mcp behavior remains unverified. this vm has codex proxy access but no cursor sign-in or api key. authentication prevents reaching either the original MODULE_NOT_FOUND on main or a successful workspace-files tool call on the pr. disabled-server behavior, same-name project/user precedence, ordinary cursor mcp servers and t3 mcp coexistence therefore remain unverified through a real cursor agent. no mock result is substituted for that missing proof. an authenticated cursor environment is still required before merge.

native desktop/mobile clients, windows/macos paths, and remote/relay/tunnel modes were not exercised. the web client ran locally on linux.

Reviewed head 89a2e13.

The approach addresses the reported stdio path failure without requiring machine-specific paths in tracked configuration. An isolated Windows probe with SDK 1.0.35 confirmed that the resolved script starts and completes MCP initialization. Preserving project precedence and disabled-server state is also the right approach.

One issue remains: the SDK still starts the original file-defined server alongside the injected copy. If ${workspaceFolder} appears only in an environment value, both commands can start successfully.

For example, use a working command with:

I reproduced one initialized process without the override and two initialized processes with it. This can duplicate startup side effects and resource usage. Could the resolved definition replace the original before startup, rather than relying on the original to fail?

Missing ${env:NAME} values also remain literal. That is a separate limitation outside this PR's workspace-variable fix.

These probes validate SDK startup behavior, not a full authenticated T3 Cursor tool call.

pushed 9b2fbefcf9d7e513fd65ca4d4c7369e38363b923 to the existing contributor branch without force. merged github/main with a merge commit and preserved both the workspace loader and main's orchestration prompt. all 29 checks now pass; git.cafe reports no conflicts.

@JeremyMoeglich the env-only case is now left with the sdk, as is cwd-only. the existing adapter case failed with both unwanted injections before the fix and passes now. blacksmith vp run check:changed passed format, lint, knip, unused-patch validation, 39 affected package typechecks, and 23 tests. all 22 cursor adapter tests passed separately.

i also ran the real sdk 1.0.38 workspace initialization path with isolated state and real stdio mcp handshakes:

this mitigates the concrete env-only duplicate, but does not fully replace file definitions before startup. one independent reviewer still blocks merge because a command may tolerate a literal placeholder argument and initialize twice. the sdk has no public per-server suppression option; dropping project/user setting sources would also drop unrelated settings. the second reviewer hit a provider rate limit before returning a verdict. i am leaving these limitations visible rather than widening this change.

additional compatibility concern from review: the loader schema drops the sdk's startupTimeoutSec field on injected definitions. this remains unresolved. corrupt disabled-server state deliberately fails closed in the current implementation, preserving the prior takeover's safety decision.

authenticated cursor use through the t3 client remains unverified because this vm has no cursor credentials. macroscope's human approval also remains required. this pr is not ready to merge despite green ci. no labels changed; no merge, close, rebase, or force-push. the blacksmith worker is stopped; no dev server was started.

updated takeover at 1b60d28cb686f9adac8f3d3efbe4ef21ec2f99de. merged current github/main with a merge commit and pushed twice to the existing contributor branch without force. no conflicts remain.

addressed the review findings within the existing loader and adapter case:

• resolve editor variables throughout stdio commands, all arguments, env and cwd, including wrapped commands.
• resolve unset ${env:NAME} to an empty string and default injected cwd to the workspace.
• read disabled state only when an override qualifies, cache it, and retain fail-closed validation for overrides.

both regression cases failed before their fixes. blacksmith vp run check:changed passed format, lint, knip, unused-patch validation, 39 affected package typechecks and 23 tests. all 22 cursor adapter tests also passed separately. two independent final-head reviews found no remaining code findings. the two fixed bot threads are resolved on github and git.cafe. the final bot suggestion to restore launch-path-only qualification was declined and resolved because it contradicts the human review's explicitly accepted sdk tradeoff.

real sdk 1.0.38 startup probe, using actual stdio mcp handshakes:

known sdk limitation: file clients start before deduplication, so an unresolved literal copy can also start. this follows the review's preference to resolve supported configurations rather than restrict overrides to executable paths. http/sse and plugin handling remain unchanged.

authenticated cursor execution through the t3 client remains unverified because this vm has no cursor credentials. the sdk startup probe does not establish an authenticated agent turn. macroscope's human approval remains outstanding.

no ui changes or new test files. final pr remains five files (+359/-2). no merge, close, rebase, force-push, or label action. the blacksmith worker is stopped; no dev server was started and no task process is retained.

ci: all 29 checks are green on the final head; github reports CLEAN / MERGEABLE and no unresolved review threads remain. this remains waiting, because authenticated cursor client verification and human approval are outstanding.

Reviewed head 4ea0d8d.

Resolving .cursor/mcp.json on the T3 side is the right approach. However, this head now resolves too little, partly because of my earlier comment about duplicate processes. I'd rather accept an occasional duplicate and resolve what Cursor IDE resolves.

Why the duplicate isn't worth avoiding

The Cursor SDK starts every server in mcp.json itself and has no public option to skip one. I checked this through SDK 1.2.0. That means T3's resolved copy always runs next to the SDK's own copy. Usually the SDK's copy fails, because its path still contains a literal ${workspaceFolder}, so only T3's copy runs. A duplicate only happens when the literal version starts anyway. Narrowing the rule to avoid that case leaves other servers not working at all.

What this head misses

Tested with T3's bundled SDK 1.0.38 on Windows, using real MCP handshakes:

The proto run form is my own config from #22199. In a real T3 Cursor turn on the current Nightly, that server fails during tool discovery.

Two more differences from Cursor IDE also break it:

• Unset ${env:NAME}: Cursor IDE passes an empty string. My IDE logs show the server receiving HOROS_CONFIG_PATH=<empty>. The SDK and this PR pass the literal text ${env:HOROS_CONFIG_PATH} instead.
• Working directory: for a server without cwd, Cursor IDE starts it in the workspace. The SDK uses the T3 server's working directory.

Suggestion

For every stdio server that contains an editor variable or an unset ${env:…} anywhere in its definition:

1. Resolve editor variables in command, all args, env and cwd.
2. Resolve unset ${env:…} to an empty string.
3. Default cwd to the workspace.
4. Pass it at agent level as this PR does now, and keep the disabled-server handling.

Document the possible duplicate as a known SDK limitation. Longer term, the SDK already has an internal excludeProjectMcp option. A public version would let T3 skip the SDK's own file copies and remove the duplicate entirely.

Verification scope: startup probes ran with SDK 1.0.38 as bundled with T3 Nightly. The authenticated Cursor turn ran on the released Nightly, not on this branch.

Re your comment: verified through a signed-in T3 Cursor thread. On head 1b60d28cb6 the ${workspaceFolder} server starts and its tool call succeeds, and the disabled server stays off. On main the same server never starts.

Setup: an isolated dev server with a fresh home, a fake project and no seeded data. Cursor was signed in through Settings → Providers, the model was GPT-5.4 Nano, and the client was web on Linux. The project's .cursor/mcp.json defines two stdio servers that run the same local script:

~/.cursor/projects/home-tester-projects-garden-notes/mcp-disabled.json is ["archive"]. The script appends a line to .mcp-starts.log when it starts, initializes and serves a call.

Both builds got the same prompt:

Use the read_note tool from the notes MCP server and quote its reply exactly. If that tool is unavailable, reply only with: notes server unavailable. Then answer yes or no: is any tool from an MCP server named archive available to you? Do not quote errors, list servers, run shell commands or read files.

main (8e6a732305):

main (8e6a732305): signed-in Cursor thread (GPT-5.4 Nano) reports the ${workspaceFolder} notes server unavailable and no archive tools

PR head (1b60d28cb6):

PR head (1b60d28cb6): the same thread calls notes_read_note and quotes its reply; the disabled archive server is not available

notes started once, with the resolved path and the workspace as cwd. archive never started. Not covered: Windows and macOS paths, the desktop and mobile clients, and remote or relay connections. The branch now conflicts with main; I've left that merge to you.

Tested head 1b60d28 on Windows 11 in a real signed-in Cursor thread. The fix works, including my own setup from #22199. I found one Windows-only test failure and two housekeeping items.

Setup: a fresh clone, run as a separate t3 serve instance from source with its own --base-dir. It used Cursor SDK 1.0.38 and Composer 2.5. One probe MCP server was configured seven ways in .cursor/mcp.json, and the thread called each tool:

In both duplicate cases, the agent called the resolved copy; the process IDs match.

My real config, proto run node -- ${workspaceFolder}/apps/horos_mcp/src/index.ts with HOROS_CONFIG_PATH: "${env:HOROS_CONFIG_PATH}" unset, also works. The thread called its db tool and got a result. On the released Nightly, the same server fails during tool discovery.

Windows test failure: adapter.test.ts › "starts mcp.json servers that use Cursor's workspace variables" fails on Windows; the other 21 tests pass. On Windows, git rev-parse --show-toplevel returns C:/Users/..., while the test expects the native path C:\Users\... in args, env and cwd. The runtime behavior is correct, because Windows accepts both forms. The test's expected values should use git's output, or normalize both sides.

Housekeeping:

• The PR description still says only the executable or leading non-flag argument qualifies, and that env-only, cwd-only and trailing-argument placeholders stay with the SDK. That no longer matches the code.

Thank you, Jeremy, for testing 1b60d28 on Windows 11 in a signed-in Cursor thread. Yours is the first run of this branch on Windows, and it covers every shape your October review asked for. Wrapped commands like proto run node -- ${workspaceFolder}/…, cwd, env and unset ${env:…} all start with resolved values. Servers without placeholders stay with the SDK, and a server in mcp-disabled.json stays hidden. It also shows that your own #22199 server reaches its db tool, where the released Nightly fails during tool discovery. That review is what widened the change from launch paths to the whole stdio definition, with the duplicate accepted as a known SDK limitation.

Thanks too, Maria, for the takeover work on that review, and for your October 28 run in a real dev environment. It showed the client and provider path working on the branch, and it established that only a signed-in Cursor run could prove the fix.

Noted on the two open points:

• Windows test: the failure is real. The test builds its expected paths natively, while the loader uses the output of git rev-parse --show-toplevel. Maria owns the branch, so we'll offer the test fix on a separate branch for her to take or leave.
• Description: the Change and Verification sections still describe the earlier rule, under which only the executable or leading script path qualified. We'll list the exact stale sentences with that offer.

Follow-up to Jeremy's Windows run: @maria-rcks, here is the test fix as an offer on a separate branch, so your branch stays yours.

Commit: 57c65db617 on only21mil/t3code branch fix/i22199-cursor-provider-fails-to-start-project-m-offer. It fast-forwards from your head 1b60d28:

What it fixes: "starts mcp.json servers that use Cursor's workspace variables" built its expected args, env and cwd with Node's path, while the loader uses the output of git rev-parse --show-toplevel. Git prints C:/Users/… on Windows, so the test failed there even though the loader's output is correct. The test now reads the expected root from the same git command. It is test-only: adapter.test.ts +15/−10, and the loader is unchanged.

Verification:

• To reproduce the Windows mismatch on Linux, a git wrapper printed the project root in an equivalent but different spelling (<dir>/./workspace). On 1b60d28 the case failed with the same three fields Jeremy saw (1 failed, 21 passed). With this commit all 22 pass, both with the wrapper and without it.
• With the loader temporarily switched to cwd instead of git's root, the case fails, so it still covers the project-root lookup.
• vp run check:changed passes, and so do all 118 provider-cursor tests.

What it can't clear: nothing here ran on Windows. Jeremy, if you can rerun the adapter test on Windows with this commit, that would confirm it. It does not merge main either, so the PR still conflicts with main.

The PR description also still describes the earlier launch-path-only rule. The stale sentences and suggested wording are below, in case they help.

Happy to push this commit to your branch if you'd like. Just say so.