Skip to content

[Resolved, not a bug] mcp_session() timeouts were caused by duplicate registration, not Positron #238

Closed

Description

@xni7

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
  • MCP client: Claude Code 2.1.293 (VS Code extension running inside Positron)
  • Server config: Rscript -e "btw::btw_mcp_server()"

Steps to reproduce

  1. In the Positron R console, run btw::btw_mcp_session() (also run from ~/.Rprofile).
  2. From the MCP client, call list_r_sessions. It returns 1: my-project (Positron).
  3. Call select_r_session(1). It succeeds.
  4. 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.

Activity

  1. 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
  2. xni7 commented on Oct 7, 2026

    @xni7
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions