[FEATURE] Allow MCP servers to opt-in to /btw side conversations

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I build an MCP plugin that needs to interact with users while Claude is working. /btw seems like the right place for this - it's already a side channel that doesn't interrupt the main task. But it denies all tool access, MCP tools included, so my plugin can't do anything there.

The docs say this is by design: "/btw is the inverse of a subagent." Full context, no tools. That makes sense for built-in tools, you don't want a side question accidentally running rm -rf or editing files. But MCP tools that just query external services don't touch the filesystem or modify the conversation. They return data. Blocking them doesn't buy you safety, it just blocks functionality.

If a user wants to check something via an MCP plugin while Claude is mid-refactor, they either interrupt the main conversation (adds to context, breaks flow) or wait. Both are worse than what /btw could offer.

Proposed Solution

Let MCP servers declare specific tools as available in side conversations:

{
  "tools": [
    { "name": "get_status", "sideConversation": true },
    { "name": "run_migration", "sideConversation": false }
  ]
}

Then change /btw's canUseTool from a blanket deny to a filtered one:

canUseTool: async (tool) => {
  if (tool.source === 'mcp' && tool.sideConversation) {
    return { behavior: "allow" };
  }
  return { behavior: "deny", message: "Side questions cannot use this tool" };
}

Built-in tools stay denied. Only MCP tools that explicitly opt in get through. Default is false, so existing servers are unaffected.

This works with the existing permission model. deny > ask > allow still applies, managed enterprise settings can lock things down via allowManagedMcpServersOnly, side conversations stay ephemeral.

Two things that would also need attention:

1. /btw is an immediate command so UserPromptSubmit hooks don't fire. Plugins that bootstrap via hooks would need something like a SideConversationStart event to set up state.

1. maxTurns is 1 right now. An MCP tool call that returns data needs at least one more turn for the model to format the response. Something like 3 would cover that without enabling long-running side sessions.

Alternative Solutions

What I do today:

• Interrupt the main conversation to call MCP tools (works, but clutters context and breaks focus)
• Wait for the agent to finish (works, but you lose the whole point of having a side channel)
• Second terminal with claude --resume (works, but feels like overkill for a quick status check)

Other approaches:

• A user-level whitelist (sideConversationTools: ["mcp__myserver__*"]) would work but puts the configuration burden on users instead of letting plugin authors declare what's safe
• #26143 proposed /peek (query with context rewind) - different approach to a similar problem

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

Claude is refactoring a handful of files, agent is running. I want to know if staging is healthy before pushing whatever Claude is about to finish. I type /btw what's the status of staging? and my deployment MCP server's get_status tool responds in the overlay. Turns out there's an error spike, so I pull logs with /btw show me recent errors. Now I know to hold off on pushing, and none of this touched the main conversation's context.

Additional Context

The docs position /btw and subagents as opposites:

/btw (full context, zero tools)  <-->  subagent (zero context, full tools)

Nothing lives between them. Opt-in MCP tools in /btw would fill that gap for read-only queries against external services.

Most of the plumbing is already there. The system prompt generation includes MCP tool definitions in /btw today, the model sees the tools, it just can't call them. The fork context passes full conversation history. The only thing standing in the way is the blanket deny in canUseTool. And there's precedent: the Skill tool's fork execution already runs in a forked context with the parent's permission model passed through.

Related issues:

• #14804 - original /btw tracking issue. @bcherny said "experimenting, more to come"
• #26143 - /peek mode proposal
• #7296, #26252, #30280 - MCP tool inheritance in subagents (same pattern of MCP tools being unavailable outside the main conversation)