Isolated Cursor personas

Ideas Feature Requests
, , ,
1

Feature request for product/service

Cursor IDE

Describe the request

Isolated personas for MCP credentials, skills, and tools

I work with several customers at once, plus our own systems. Each engagement has its own MCP servers, OAuth sessions, API credentials, plugins, skills, and tools (Slack, mail, calendars, identity providers, internal APIs, and so on). I need a persona per customer so that work in one persona cannot see or use another persona’s clients, secrets, or instructions.

Current behaviour

  • MCP is either user-global (~/.cursor/mcp.json) or project-scoped (.cursor/mcp.json). User-global servers and their authenticated sessions are available in every window.
  • Skills, rules, hooks, and installed plugins at user scope (~/.cursor/skills, Customize → user) load for every workspace. Project files do not hide the user-level set.
  • OAuth tokens and other MCP credentials live in one store for the Cursor user. Opening customer A’s repo does not remove customer B’s tools from the agent.
  • Editor profiles isolate settings, extensions, keybindings, and snippets. They do not isolate MCP auth, skills, plugins, or the agent tool list.

Desired behaviour

A persona is a named, switchable identity with its own:

  • MCP server list and enabled tools
  • OAuth tokens, API keys, and env secrets for those servers
  • Plugins, skills, rules, hooks, commands, and subagents
  • Agent memories and any synced cloud-agent skill snapshot

Isolation requirements:

  1. The agent in persona A receives only persona A’s tools, skill text, rules, and credentials. Persona B’s servers are absent from the tool list, not merely hidden in the UI.
  2. Tool execution uses only persona A’s credential store. A prompt, skill, or hook cannot address another persona’s token.
  3. Two windows can run two personas at the same time (customer A and customer B, or a customer and our own company) without sharing MCP sessions.
  4. Switching personas does not carry the previous persona’s tool approvals, OAuth grants, or skill files into the new one.
  5. The same boundary applies in the IDE, the CLI, and Cloud Agents. A cloud agent started from persona A uses persona A’s skills and MCP grants only.
  6. Chat transcripts, memories, and hooks stay inside the persona that created them.
  7. The active persona is visible in the window (name and colour or icon) before any tool runs.

Project .cursor/ config can still add repo-specific rules and servers on top of the active persona. It must not grant another persona’s credentials.

Use case

A consultant has personas internal, customer-acme, and customer-northwind. Acme’s window has Acme’s identity provider, issue tracker, and Slack. Northwind’s window has Northwind’s. The internal window has our own systems. Asking the agent to “check yesterday’s mail” or “open the production database” resolves only against the persona that is active in that window.

Why project mcp.json is not enough

Customer work often spans many repos, tickets, and empty windows, so the boundary cannot depend on which folder is open. Secrets also cannot live in project files that get committed or copied between repos. User-level config is what makes the tools available everywhere, which is the problem.

5

I’d add one acceptance test: open two windows with different personas and have each agent list the tools, skills, and rules it can see before either one runs a tool. Persona A should not just refuse Persona B’s tools. Those tools should be absent from A’s list entirely. Then switch personas in one window and repeat the check in a fresh session so the old tool approvals and instructions do not carry over. That would catch the difference between a UI profile and a real isolation boundary.

6

Useful isolation probe for the memory half of this FR — UI hide and true isolation look identical until you force a cross-persona retrieval:

  1. Two windows / personas A and B against the same MCP memory (or Decision) server, each with a distinct scope key (customer-acme vs customer-northwind).
  2. In A, store one fact that must not leak (e.g. “Acme rejected Postgres for Redis because …”).
  3. In B, ask for that fact without naming Acme. Expected: B’s tool list never includes A’s credentials and retrieval returns empty for A’s scope — not a polite refuse after the tool already returned the row.
  4. Inspect the tool payload: does each call carry the persona/customer identity, or only the shared user token?

Separately: when memories “vanish” after a switch, are they absent from MCP results, or still returned and only dropped from the agent’s visible context? That split decides whether the bug is tool availability, scope propagation, retrieval filtering, or UI.

If you already have a config that fails one of those layers, the reproducible mcp.json + surface (IDE / CLI / Cloud Agent) would pin it.