Claude Code Source Leak: Inside Its Hardcore Communication Architecture

Recently the Claude Code source code was unintentionally published, giving developers a rare chance to examine the inner workings of this top‑tier AI programming tool beyond its black‑box prompts.

RemoteSessionManager – the central hub

The core of the communication system is the RemoteSessionManager module, which performs four essential duties: establishing connections, routing messages, handling permission requests, and sending control commands. It acts like a live‑session dispatcher, receiving server messages, delivering client messages, intercepting tool‑use permission checks, and managing reconnections.

Read/write separation: WebSocket for downlink, HTTP POST for uplink

Claude Code splits traffic by direction. Downlink (reading) uses a persistent WebSocket subscription suitable for continuous server pushes, while uplink (writing) sends user inputs and events via HTTP POST, fitting a clear, single‑shot submission model.

const url = `wss://.../v1/sessions/ws/${sessionId}/subscribe?organization_uuid=...`;
const headers = {
  Authorization: `Bearer ${accessToken}`,
  'anthropic-version': '2023-06-01',
};

The implementation refreshes the token on every reconnection, treats error 4003 as a permanent refusal (no further retries) and 4001 as a temporary outage (limited retries), and keeps the connection alive with periodic ping heartbeats.

HTTP POST payload

const requestBody = {
  events: [{
    uuid: '...',
    session_id: sessionId,
    type: 'user',
    parent_tool_use_id: null,
    message: { role: 'user', content: messageContent },
  }],
};

This design makes each user action an explicit “event node”, allowing clear failure detection and easy retries.

Layered message protocol

Messages are divided into three categories: ordinary content (assistant replies, status, tool progress), control_request (server asks the client to confirm a tool usage), and control_response (client’s answer). By separating content and control streams, the UI knows exactly what to render and the server knows whether it is awaiting user confirmation or continuing generation.

Remote tool permission approval flow

When the server sends a control_request of type can_use_tool, the client records the request, pauses processing, shows a UI confirmation dialog, wraps the user’s decision into a control_response, and sends it back. The server proceeds only after receiving the explicit approval, and any cancellation clears the pending state.

Bridge layer – local traffic hub

The bridge layer filters out internal virtual messages, deduplicates events using UUIDs and time windows, and guarantees rapid responses to control requests, preventing timeout on the server side.

Overall session sequence

// 1. Establish long‑lived WebSocket
connectWebSocket();
// 2. Receive and dispatch
onMessage(msg) {
  if (msg.type === 'control_request') handlePermissionRequest(msg);
  else renderOrDispatch(msg);
}
// 3. Send user input via HTTP POST
sendMessageToSession({ type: 'user', message: { ... } });
// 4. Return permission decision
sendControlResponse({ type: 'control_response', response: { ... } });

The analysis shows that a mature network system for an AI tool favors clear architecture and sustainability over flashy features, turning a simple terminal into a lightweight remote collaboration platform.