pi-claude-bridge

Pi extension that integrates Claude Code via the Agent SDK. Based initially on claude-agent-sdk-pi by Prateek Sunal. This fork adds streaming, MCP tool bridging, custom pi tool bridging, session resume/persistence, context sync, thinking support, skills forwarding, and many correctness fixes.

1. Provider — Use Opus/Sonnet/Haiku as models in pi, with all tool calls flowing through pi's TUI
2. AskClaude tool — Delegate tasks or questions to Claude Code when using another provider

FYI: Anthropic announced and then unannounced a change to how you would be billed for tools that use the Agent SDK like this one. It currently uses your regular subscription quota just like Claude Code.

Install

pi install npm:pi-claude-bridge

Provider

Use /model to select claude-bridge/claude-fable-5, claude-bridge/claude-opus-5, claude-bridge/claude-opus-4-8, claude-bridge/claude-opus-4-7, claude-bridge/claude-opus-4-6, claude-bridge/claude-sonnet-5, claude-bridge/claude-sonnet-4-6, or claude-bridge/claude-haiku-4-5.

Behind the scenes, pi's tools are bridged to Claude Code but it should all work like normal in pi. Bash commands get a 120-second default timeout (matching Claude Code's default) since pi's bash has no timeout by default. Skills in pi are copied over to Claude Code's system prompt so should work as they would with any other pi provider. Steering works mid-turn: a message sent while Claude is running a tool reaches it at that tool boundary, not after the whole turn finishes.

1M Context: Opus 5, Opus 4.8, and Opus 4.7 get 1M context by default. Opus 4.6 only gets 1M if you're on a Max plan or pay for Extra Usage. Sonnet 4.6 only gets 1M if you pay for Extra Usage. You will need to set provider.plan and/or provider.longContextExtraUsage for 1M context in Opus 4.6/Sonnet 4.6 as described in Configuration.

AskClaude Tool

Opt-in: set askClaude.enabled to true (see Configuration). Available when using any non-claude-bridge provider. Pi's LLM can delegate tasks to Claude Code and wait for it to answer a question or perform a task. Examples of how to use:

• "Ask Claude to plan a fix"
• "If you get stuck, ask claude for help"
• "Ask claude to review the plan in @foo.md, implement it, then ask an isolated=true claude to review the implementation"
• "Ask claude to poke holes in this theory"
• "Find all the places in the codebase that handle auth"

You could also create skills or add something to AGENTS.md to e.g. "Always call Ask Claude to review complicated feature implementations before considering the task complete."

Parameters

• prompt — the question or task for Claude Code
• mode — read (default, read files and search/fetch on web), none, or full (read+write+bash, disable this mode with allowFullMode: false in config)
• model — opus (default), sonnet, haiku, or a full model ID
• thinking — effort level: off, minimal, low, medium, high, xhigh
• isolated — when true, Claude gets a clean session with no conversation history (default: false)

Configuration

Config: ~/.pi/agent/claude-bridge.json (global) or the project Pi config directory, usually .pi/claude-bridge.json (project; merged over global).

{
  "askClaude": {
    "enabled": true,
    "allowFullMode": true,
    "defaultIsolated": false,
    "description": "Custom tool description override"
  },
  "provider": {
    "plan": "max",
    "longContextExtraUsage": false,
    "strictMcpConfig": true,
    "pathToClaudeCodeExecutable": "/home/you/.nix-profile/bin/claude"
  }
}

askClaude:

• enabled — register the AskClaude tool (default false). If it's unset, the startup notice below points this out once.
• name — override the tool's pi-side name (default "AskClaude")
• label — override the TUI label (default "Ask Claude Code")
• description — override the tool description. Default when allowFullMode: true: "Delegate to Claude Code for a second opinion or analysis (code review, architecture questions, debugging theories), or to autonomously handle a task. Defaults to read-only mode — use full mode when the user wants to delegate a task that requires changes. Prefer to handle straightforward tasks yourself."
• defaultMode — "read" (default), "none", or "full"
• defaultIsolated — start each call in a fresh session (default false)
• allowFullMode — allow mode: "full"; set false to lock it out
• appendSkills — forward pi's skills block into the system prompt (default true)

provider:

• plan (default "pro") — set to "max" if you have a Max (or Team Premium/Enterprise) Anthropic plan. This enables Opus with 1M context.
• longContextExtraUsage — set to true to enable 1M context models even if they cost money through Extra Usage on your plan. It enables Sonnet 4.6 with 1M on every plan and Opus 4.6 with 1M on Pro. Not needed for Opus 4.7 or 4.8.
• strictMcpConfig — block MCP servers from ~/.claude.json / .mcp.json (default true). Cloud MCP (Gmail/Drive via claude.ai OAuth) is always blocked.
• autoMemoryEnabled — enable Claude Code's auto-memory system (default false)
• pathToClaudeCodeExecutable — path to the claude binary. Useful if your OS/filesystem has the SDK's bundled musl/glibc binaries in a place where they can't run. For example, with Nix you can set the binary to e.g. "/home/you/.nix-profile/bin/claude".

Startup notice: the first interactive session to reach Claude Code lists whichever of provider.plan and askClaude.enabled you have left unset, then records startupNoticeShown (the date, YYYY-MM-DD) in the global config so it doesn't nag again.

Extension providers and models.json: pi's modelOverrides in ~/.pi/agent/models.json do not currently apply to extension-registered providers (like claude-bridge). Overriding contextWindow or other fields requires editing src/models.ts directly.

Tests

npm run test:unit for offline tests (tests/unit-*.mjs: queue, import, skills).

npm test for the full suite, which adds integration tests that hit APIs (tests/int-*.{sh,mjs}: smoke, multi-turn, cache, session-resume, session-rebuild, tool-message). Set CLAUDE_BRIDGE_TESTING_ALT_MODEL in .env.test for the alt-provider smoke test (e.g. openrouter/z-ai/glm-4.7-flash).

Integration tests spawn real pi and Claude Code subprocesses, so they need write access to ~/.claude for CC's session state — a sandbox that blocks it makes the next turn's --resume fail with No conversation found with session ID. The RPC harness probes for this at startup and fails fast.

Debugging

Set CLAUDE_BRIDGE_DEBUG=1 to enable debug output:

• Bridge log at ~/.pi/agent/claude-bridge.log — every provider call, session sync decision, tool result delivery, and CC's stderr. Override location with CLAUDE_BRIDGE_DEBUG_PATH.
• Per-query Claude Code CLI logs at ~/.pi/agent/cc-cli-logs/<timestamp>-<tag>-<seq>.log — the CC subprocess's own debug stream, one file per query() call. Tags are provider (main turn) or askclaude (sub-delegation). Useful when a resume fails or CC misbehaves internally — shows the CLI's own view of session loading, API requests, and tool calls.

When filing a bug about a session-resume failure (e.g. "No conversation found"), the most useful attachments are the syncResult: lines from the bridge log plus the matching cc-cli-logs/ file for the failing query.

Known issues

Sessions get rebuilt more often than they need to be, and a rebuild is expensive. The bridge rewrites Claude Code's session from pi's history whenever pi's messages move underneath it — after an abort, /compact, tree navigation, or an API error. Measured over this repo's own bridge log, a rebuild boundary loses the prompt cache roughly 58% of the time against 26% for a plain resume, so an abort-heavy session costs noticeably more than a clean one. Aborts alone are 46% of rebuilds.

Files Claude Code edits are not carried across a rebuild. CC records the post-edit contents as an edited_text_file attachment; those aren't carried, because they hang off a tool-result record rather than a prompt and so have no stable position to restore them to. The edit itself survives — it's in the history as a tool call and its result — so this costs Claude the file snapshot, not the knowledge that it made the change. @file expansions are carried.