Skip to main content
Bridge mode creates a JWT-authenticated bidirectional connection between your local Claurst process and the claude.ai web UI or IDE extensions. Once connected, you can drive the CLI session from a browser tab, share diffs live with your IDE, and sync file selections between your editor and Claude. Bridge mode is gated behind the BRIDGE_MODE compile-time feature flag and requires a claude.ai subscription.

​
Enabling bridge mode

Start a bridge session using the /bridge or /rc slash command from within an active Claurst session: 
/bridge
or use the standalone remote-control command: 
claude remote-control

​
Work modes

The standalone bridge supports three session spawn modes, configured via BridgeConfig.spawnMode:
ModeBehavior
single-sessionOne session; the bridge tears down when it ends
worktreePersistent server; each incoming session gets an isolated git worktree
same-dirPersistent server; sessions share the working directory
worktree mode is the safest option for multi-session use — each session gets its own isolated git worktree so concurrent sessions cannot conflict.

​
Transport options

The bridge crate supports three transport implementations:
TransportDescription
SSETransportServer-Sent Events over HTTP — used for CCR v2 sessions
WebSocketTransportFull-duplex WebSocket — default for ws:// URLs
HybridTransportWebSocket for reads, HTTP POST for writes — batches stream events before posting
Transport selection is automatic based on the session URL scheme and environment configuration. The HybridTransport accumulates stream_event messages for up to 100ms before posting them as a batch, which reduces request overhead during high-throughput streaming.

​
IDE integration

VS Code and JetBrains extensions connect to Claurst via direct-connect. Once connected:
  • Live diff viewing — file changes made by Claude appear in your IDE’s diff viewer as they happen
  • File selection sync — selecting files in your IDE forwards them to Claude as context
  • Status indicator — your IDE shows a status badge reflecting the current bridge connection state (ready, connected, reconnecting, failed)
The IDE extensions connect to the local direct-connect server started by Claurst’s bridge initialization. No cloud relay is involved for the IDE connection itself.

​
JWT authentication

Every bridge API call is authenticated with a JWT. The cc-bridge crate’s jwt module decodes the payload without signature verification to read the exp claim, and the createTokenRefreshScheduler proactively schedules token refreshes 5 minutes before expiry. On token expiry:
  • V1 sessions: the new OAuth token is injected directly to the child process stdin
  • V2 sessions: reconnectSession is called to trigger server re-dispatch with a fresh JWT (V2 validates the session_id JWT claim directly)

​
Trusted device tokens

When the tengu_sessions_elevated_auth_enforcement gate is active, bridge API requests include an X-Trusted-Device-Token header. This token is derived from a SHA-256 hash of device-identifying information (hostname, username, home directory path) and enables elevated security tiers for persistent bridge registrations. The device fingerprint is computed in the trusted_device module of cc-bridge: 
// Collects hostname + USER env var + home directory path
// SHA-256 hash → first 16 chars of lowercase hex
device_fingerprint() -> String

​
KAIROS mode

KAIROS is an always-on proactive assistant mode, gated behind the PROACTIVE / KAIROS compile-time feature flags. When active, Claurst does not wait for you to type — it watches, logs, and proactively acts on things it notices.
KAIROS is an internal Anthropic feature and is absent from external builds. It is documented here for completeness in the Claurst specification.

​
How KAIROS works

KAIROS maintains append-only daily log files at ~/.claude/memory/logs/YYYY/MM/YYYY-MM-DD.md. It writes observations, decisions, and actions throughout the day. On a regular interval, Claurst sends <tick> prompts to Claude, which then decides whether to act proactively or stay quiet. The tick system has a 15-second blocking budget — any proactive action that would block your workflow for more than 15 seconds is deferred. This keeps KAIROS helpful without being disruptive. When KAIROS is active, responses use Brief mode: extremely concise output designed for a persistent assistant that should not flood the terminal.

​
KAIROS-exclusive tools

ToolWhat it does
SendUserFilePush files directly to the user (notifications, summaries)
PushNotificationSend push notifications to the user’s device
SubscribePRSubscribe to and monitor pull request activity
These tools are only available when the PROACTIVE/KAIROS feature flag is enabled.

​
ULTRAPLAN

ULTRAPLAN offloads complex planning tasks to a remote Cloud Container Runtime (CCR) session running Opus 4.6, giving it up to 30 minutes to produce a deep plan.
ULTRAPLAN is an internal Anthropic feature gated behind additional compile-time flags and is absent from external builds.

​
How ULTRAPLAN works

1

Task identification

Claurst identifies a task that requires deep, extended planning beyond what is practical in a local session.
2

Remote session spin-up

A remote CCR session is created using the tengu_ultraplan_model config, running Opus 4.6.
3

Polling

Your terminal enters a polling state, checking every 3 seconds for the planning result. Meanwhile, a browser-based UI lets you watch the planning happen and approve or reject the output.
4

Result delivery

When the remote plan is approved, the sentinel value __ULTRAPLAN_TELEPORT_LOCAL__ is used to return the result to your local terminal, continuing the session with the completed plan in context.

Build docs developers (and LLMs) love

Get started for freeTalk to us