Experiment: exposing Positron's live R/Python sessions to Codex and other agents via MCP

[kv9898]

I've really enjoyed using Positron's built-in Posit Assistant. In particular, what I find valuable isn't just having an AI assistant inside the IDE, but its integration with Positron's live R/Python sessions — being able to understand and interact with the interpreter state makes it considerably more useful for data-science workflows than a coding assistant that only sees the filesystem and terminal.

However, Posit Assistant currently doesn't support authenticating to OpenAI through a ChatGPT/Codex subscription (#14180). My institution provides me with a Codex subscription, so using OpenAI models through an API provider separately would effectively mean paying again for access I already have.

That got me wondering whether there was another way to approach the problem.

Rather than trying to make Codex a model provider for Posit Assistant, I thought it might be possible to reproduce some of the Posit Assistant experience from the other direction: expose Positron's live runtime capabilities to Codex through a local MCP server.

That led me to build an experimental extension:

kv9898/positron-mcp (you can download it from marketplace)

The basic architecture is:

Codex / other MCP-compatible agent
              │
              │ MCP (localhost)
              ▼
        positron-mcp
              │
              │ Positron extension APIs
              ▼
      live R/Python session

You can do, for example, this:

The important part is that the agent interacts with the same live interpreter session that Positron is already using, rather than launching a separate Rscript or Python process. This means an external agent can potentially reason about objects and state that already exist in an interactive analysis session.

My intention isn't to reproduce or replace Posit Assistant. Rather, this is an experiment in making some of Positron's particularly useful runtime-aware capabilities available to external AI agents whose model/authentication arrangements may be different.

One nice consequence of keeping this behind MCP is that the two concerns remain fairly cleanly separated:

• Positron owns the IDE and R/Python runtime integration;
• positron-mcp translates selected runtime capabilities into MCP tools;
• Codex (or another MCP client) handles the agent loop, model access, and authentication.

While working on this, I noticed that the idea overlaps quite closely with #9284, particularly the discussion there around exposing Positron context to third-party AI extensions and the possibility of using MCP for that purpose.

It has also made some of the current extension API limitations much more concrete. For example, interacting programmatically with the live interpreter is possible, but there are still gaps around things such as silent evaluation/execution with results returned to the caller (related to #10505). These become especially noticeable when trying to expose the runtime as a proper request/response tool for an external agent.

The project is still experimental, but I thought it might be useful to share because it provides a working example of this kind of third-party integration.

I'd be particularly interested in feedback from the Positron team on:

• whether this general architecture is aligned with how you envision third-party AI/agent integrations working;
• whether there are Positron runtime APIs that the extension could be using more appropriately;
• whether exposing more of the live interpreter through the public extension API is something you'd be open to;
• whether a built-in Positron MCP/context surface along the lines discussed in Assistant: Register tool(s) to fetch Positron context (for third party extensibility) #9284 is still something you're considering;
• and whether any lessons from this experiment could be useful for that work.

I'd also be very happy to hear from anyone interested in trying it with other MCP-compatible agents. The extension itself doesn't depend on Codex specifically; Codex was simply the reason I started experimenting with it.

This is an independent community project and is not affiliated with or endorsed by Posit.

[jmcphers]

We do think exposing Positron as an MCP that allows for inspecting sessions, running code, etc. is very interesting, and we plan to have an experimental first-party MCP available in an upcoming release. Stay tuned for details!

[kv9898]

We do think exposing Positron as an MCP that allows for inspecting sessions, running code, etc. is very interesting, and we plan to have an experimental first-party MCP available in an upcoming release. Stay tuned for details!

Thanks for the reply @jmcphers ! Please can you also refer #15923 to someone to look at? I think many users look forward to that PR and I think my implementation is minimal. Many thanks in advance.