Where does the bug appear (feature/product)?
Somewhere else…
Describe the Bug
When running a Cloud Agent via “My Machines”, the worker does not appear to load or forward MCP servers configured on the host machine. The local Cursor CLI can see and approve the MCP servers from .cursor/mcp.json, but the worker debug startup log reports mcpConfigSummary: {hasMcpConfig: false, serverNames: }. This makes MCP servers unavailable to Cloud Agent sessions unless they are manually duplicated into Cloud settings.
Steps to Reproduce
- Configure MCP servers in the host user-level config at ~/.cursor/mcp.json.
- Start a My Machines worker from a repo:
agent --approve-mcps --trust worker --worker-dir /workspaces/obsidian --name ona-1 --debug start --verbose
- Confirm local CLI sees the MCP servers:
agent mcp list
In my case this reports servers like LangSmith, mongodb, netlify, and datadog as ready.
- Check the worker startup debug log.
- Observe that the worker reports:
mcpConfigSummary: {hasMcpConfig: false, serverNames: , stdioServerCount: 0, httpServerCount: 0}
- Also tried symlinking repo config to user config:
ln -s /home/vscode/.cursor/mcp.json /workspaces/obsidian/.cursor/mcp.json
Then restarted the worker, but the worker still reported hasMcpConfig: false.
Expected Behavior
A My Machines worker should honor the same local MCP configuration that Cursor/SSH/CLI uses on the host, or otherwise provide a documented way to load/forward local MCP servers into Cloud Agent sessions. If agent mcp list can see approved MCP servers for the same user/workspace, the worker should expose them to Cloud Agent sessions too.
Operating System
Linux
Version Information
CLI Version 2026.05.15-3f71873
Model Auto
Subscription Tier Enterprise
OS linux (x64)
Terminal unknown
Shell bash
Does this stop you from using Cursor
Yes - Cursor is unusable
The worker not reading ~/.cursor/mcp.json is expected behavior, not a bug.
The hasMcpConfig: false in the startup log is also expected — it reflects the state before any session is claimed. MCP config arrives when the backend pushes it at session start.
To get MCPs working with your worker:
-
Configure your MCP servers in the Cloud Agents dashboard (Team Settings > Integrations & MCP)
-
When starting a Cloud Agent session, enable the MCP toggles for the servers you want
-
Stdio MCPs (like local tools) will run as child processes on the worker’s network. HTTP MCPs are handled by Cursor’s backend.
Full docs: Self-Hosted Pool > MCP servers
A couple of related threads cover the same setup: How to use MCPs with self-hosted agents? and Self hosted agents on K8s, connecting MCPs.
One heads up: there’s a known issue where portal-configured stdio MCPs sometimes don’t start in cloud agent sessions. Our team is actively working on a fix. If you configure MCPs via the dashboard and they still don’t show up at runtime, let us know here.
Curious about what’s the rationale behind the decision why agent shouldn’t load MCP servers from the host compared to using ssh where they can? For normal cursor cloud agent it makes sense, but for the “my machine” use cursor agent, the host env is prepared beforehand, and the user experience is inconsistent that cursor using SSH works but not through cursor agent. Setting things on cursor dashboard can technically work but we have to copy over all the existing setups to cursor which is less maintainable.
When you connect via SSH, Cursor runs a full IDE session on the remote machine. It reads ~/.cursor/mcp.json the same way it would locally – same code path, same behavior.
My Machines workers are different: they’re headless processes that can be claimed by different sessions. Because the worker doesn’t know upfront which user or which MCP servers a session will need, config is delivered at session start based on what you’ve set up in the dashboard. That’s why local mcp.json isn’t read.