Posit shipped Positron 2026.10 on November 4 with an experimental feature they call the Positron MCP. Flip one setting, MCP: Enabled, and the IDE starts a Model Context Protocol server that any agent harness can connect to. Posit has tested it with Claude Code (extension and CLI), Codex (extension and CLI), OpenCode, Kiro, Gemini, and Copilot CLI.
The pitch is real session awareness. Without the MCP, an agent inside Positron behaves like an agent in a plain terminal: it cannot see your data, your consoles, or your plots, and any R or Python it runs goes through shell commands you watch after the fact. With the MCP on, the agent sees your loaded data, reads your consoles, runs code in them, and can pick up work you started.
I have not enabled it against a live session yet. I read the announcement twice, because the security paragraph at the end deserves the same attention as the feature list. Here is the checklist I would work through first.
The post lists what the connected agent gains: your loaded data as context, your R and Python consoles (it can run code in them, annotated with the agent name in the Console pane), your plots, and enough session state to discuss an error without copy-pasting. It can pick up work you started, and you can finish work it starts.
Two details matter more than the rest. First, loaded data becomes model context, which means whatever is in the session at connect time, including a dataframe you joined five minutes ago, is readable by the model behind the harness. Second, code execution moves into your consoles and runs with your user credentials. Those are the two things your guardrails have to answer for.
Setup is deliberately easy. Run Positron MCP: Add to Coding Agent and Positron writes the config for a harness it recognizes. For anything else, Positron MCP: Show Connected Agents has a Copy Connection Details option. No manual URL typing.
One design choice is quietly the best guardrail in the feature: MCPs start inside projects. Each window with a different project gets its own server, and a window with no folder open does not run one at all. The blast radius of an enabled MCP is the project, not the machine. Build the rest of your setup on that fact.
The server is project-scoped, so make the project worth scoping. I would not enable the MCP in the window where I keep scratch extracts, CSVs with real customer rows, or an .Renviron full of tokens. Data that becomes agent context should be data you already decided a model is allowed to see. In practice that means a dedicated analysis project per agent-enabled effort, and the credentials live in the keychain, not the workspace.
Here is the nuance most checklists will miss. Your existing deny rules police Bash. Code that the agent sends through the Positron MCP into your R console is not Bash, so a rule like Bash(rm -rf:*) never sees it. In Claude Code, MCP tools are permissioned by server and tool name, so the rules that actually guard this surface look like this:
{
"permissions": {
"ask": [
"mcp__positron"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(git push:*)"
]
}
}
The exact server key is whatever name Positron registers, check it with /mcp after the first connect. Asking on the bare server name means every Positron tool call prompts before it runs, which is the right default for a console with your credentials attached.
If your Claude Code setup loads six global MCP servers, they all join the session next to Positron's. Every connected server spends tokens before your first prompt, I once measured nine servers costing 41k tokens before the first prompt. Launch the project strict, so only the project's own .mcp.json loads:
cd agent-analysis-project
claude --strict-mcp-config
If you genuinely need one more server, allowlist it explicitly with enabledMcpjsonServers instead of reopening the global config.
Posit's own words on the risk: the MCP can execute arbitrary code in your consoles, that code runs with your user credentials, and exposing the MCP to an agent is equivalent to giving it unrestricted shell access. Claude Code 2.1.314 added a setting that belongs in exactly this setup (changelog):
{
"permissions": {
"blockWritesOutsideWorkingDirectories": "Write"
}
}
With that in place, Edit, Write, and NotebookEdit refuse paths outside the working directories in every permission mode. The console and the shell are both open doors; this at least fences where files can land.
When the MCP runs code, the console line carries the agent's name, and the MCP Status Bar setting puts an icon on every connected harness. That is your audit trail, and it is a good one: review it the way you review a diff. Posit frames the feature as working alongside the agent, it picks up what you started, you finish what it starts. That loop only holds if you actually read what ran.
The security section is refreshingly direct. Enabling the MCP delegates trust decisions to your agent harness. Most harnesses prompt before dangerous operations, but not all. Read that as: your permission config is the security model now. The IDE handed over the keys, and whether the driver asks before each turn is decided by your settings, not by Positron. The discipline that keeps any coding agent out of trouble applies double when the tool under control is a live R or Python session with your credentials.
Two changes would move this from experimental to default-on for me. A read-only tier, where the agent sees data and plots but cannot execute in consoles, would cover most of the questions I would actually ask. Per-tool consent inside Positron, instead of full delegation at enable time, would close the rest. Until then: enable per project, ask on every tool call, fence the writes, and read the annotations. It is a good feature shipped with an honest warning label. Take both seriously.