src/bridge/ and is gated behind the BRIDGE_MODE feature flag — it is stripped entirely from non-IDE builds.
Architecture
Key files
bridgeMain.ts
bridgeMain.ts
Main bridge loop. Starts the bidirectional channel between the IDE extension and the Claude Code core. This is the entry point for bridge mode execution.
bridgeMessaging.ts
bridgeMessaging.ts
Message protocol implementation — serialization and deserialization of all messages exchanged between the IDE and CLI.
bridgePermissionCallbacks.ts
bridgePermissionCallbacks.ts
Routes permission prompts from Claude Code’s permission system to the IDE, so the user is prompted via the IDE UI rather than the terminal.
bridgeApi.ts
bridgeApi.ts
The API surface exposed to the IDE extension. Defines what the IDE can call on the CLI backend.
replBridge.ts
replBridge.ts
Connects the active REPL session to the bridge channel, wiring the interactive session into the bidirectional protocol.
jwtUtils.ts
jwtUtils.ts
JWT-based authentication utilities. The CLI and IDE extension exchange signed tokens to verify each other’s identity before any messages are processed.
sessionRunner.ts
sessionRunner.ts
Manages the lifecycle of a bridge session — creation, execution, and teardown.
createSession.ts
createSession.ts
Creates new bridge sessions, initializing the state and channel for a fresh IDE connection.
trustedDevice.ts
trustedDevice.ts
Device trust verification. Ensures the IDE extension connecting to the CLI is on a recognized, trusted device.
workSecret.ts
workSecret.ts
Workspace-scoped secrets used as part of the authentication handshake between the CLI and IDE.
inboundMessages.ts
inboundMessages.ts
Handles messages arriving from the IDE, dispatching them to the appropriate handlers in the CLI core.
inboundAttachments.ts
inboundAttachments.ts
Handles file attachments sent from the IDE to the CLI (for example, files dragged into the IDE chat interface).
Authentication
The bridge uses JWT-based authentication to secure the channel between the IDE extension and the CLI backend.Session secret is established
When the CLI starts in bridge mode, it generates a workspace-scoped secret via
workSecret.ts.IDE extension authenticates
The IDE extension presents its credentials.
jwtUtils.ts validates the JWT and confirms the device is trusted via trustedDevice.ts.Permission proxying
When a tool requires user approval in bridge mode, the permission prompt is not shown in the terminal. Instead,bridgePermissionCallbacks.ts forwards the prompt to the IDE, where the user approves or denies via the IDE’s native UI.
The same permission rules and modes (
default, plan, bypassPermissions, auto) apply in bridge mode. The only difference is where the prompt appears.Feature flag
The bridge is controlled by theBRIDGE_MODE feature flag using Bun’s dead-code elimination:
src/bridge/ directory is absent from standard CLI builds, keeping the binary lean for non-IDE usage.
Related
- Architecture — Feature flags and the build system
- Permission system — How permission proxying integrates with the core permission layer