You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Resolved, not a bug] mcp_session() timeouts were caused by duplicate registration, not Positron #238
Update (2026-10-07): not a Positron bug. In my repro, btw_mcp_session() was called by hand and from ~/.Rprofile, so the R process held two mcptools sockets. With a single registration, the Positron console handles repeated tool calls fine. The original report is kept below for reference.
Summary
An R session in the Positron console registers with the MCP server (it appears in list_r_sessions), but every tool call sent to it times out after 120 seconds. The same
setup works correctly from plain R started in a terminal.
Environment
macOS Tahoe 26.7.1 (aarch64)
R 4.6.1
Positron 1.130.0 (from the app's Info.plist)
btw 1.5.0, mcptools 1.0.3, later 1.4.8, nanonext 1.10.3
In the Positron R console, run btw::btw_mcp_session() (also run from ~/.Rprofile).
From the MCP client, call list_r_sessions. It returns 1: my-project (Positron).
Call select_r_session(1). It succeeds.
Call any tool, e.g. btw_tool_run_r with ls(), while the console is idle at >.
Expected: the code runs in the Positron session and returns its objects. Actual:Timed out waiting for a response from the selected R session after 120 seconds.
What I tried
Restarting R, reinstalling btw/mcptools, and reconnecting the MCP server: same result.
Plain R in a terminal (same machine, same project, same .Rprofile): works. interactive() is TRUE, and objects created in that console are visible to the tools.
Possibly related
When no session is selected or registered, tools quietly run in a fresh non-interactive
R process (interactive() == FALSE, empty environment). This made it look as if the
Positron session was working when it wasn't. A warning or a visible flag when falling
back would help.
btw_tool_env_describe_environment on an empty global environment returns a result with text: null. The client rejects it with an MCP schema validation error.
Debugging details
btw tools run fine when called directly in the Positron console
(btw_tool_sessioninfo_platform() takes 0.24 s).
later, promises, and nanonext::recv_aio() → as.promise() callbacks all fire
normally in the Positron console when idle.
The session answers the first list_r_sessions probe. After that, a forwarded tools/call never arrives: tracing mcptools:::mac_open in the session shows no call. nanonext::unresolved(mcptools:::the$raio) is TRUE, and there is no [mcptools] session error message. The session then stops answering list_r_sessions probes as well.
The server log shows TO SESSION: {"method":["tools/call"], ...} for each failed request.
Plain terminal R on the same machine, with the same packages and .Rprofile, works reliably.
Closing a second Claude Code instance (a second btw_mcp_server()) made no difference.
changed the title [-]mcp_session() in Positron console registers but never responds to tool calls (terminal R works)[/-][+][Resolved, not a bug] mcp_session() timeouts were caused by duplicate registration, not Positron[/+]on Oct 7, 2026
I couldn't reproduce this with a single registration. My steps called btw_mcp_session() manually while ~/.Rprofile also called it, which left the session holding two mcptools sockets. The same symptoms (first probe answered, later tools/call never arrives, 120s timeout) also happened with radian in VS Code, so it isn't specific to Positron.
Registered once, the Positron console works for repeated calls. Closing as not planned. A small suggestion: btw_mcp_session() could warn or do nothing when the session is already registered, which would have saved a lot of debugging.
Activity
[-]mcp_session() in Positron console registers but never responds to tool calls (terminal R works)[/-][+][Resolved, not a bug] mcp_session() timeouts were caused by duplicate registration, not Positron[/+]xni7 commentedon Oct 7, 2026
I couldn't reproduce this with a single registration. My steps called
btw_mcp_session()manually while~/.Rprofilealso called it, which left the session holding two mcptools sockets. The same symptoms (first probe answered, latertools/callnever arrives, 120s timeout) also happened with radian in VS Code, so it isn't specific to Positron.Registered once, the Positron console works for repeated calls. Closing as not planned. A small suggestion:
btw_mcp_session()could warn or do nothing when the session is already registered, which would have saved a lot of debugging.