Claude Code 跨进程与远程通信架构深度剖析报告

引言与全局架构概览

在现代的 AI 代理工具链中，将 UI 呈现层与任务执行层解耦是一项至关重要的架构设计。Claude Code 通过 src/bridge/ 模块实现了极为精妙的跨进程/跨端通信隔离架构 (IPC & Remote Bridge)。

Bridge 模块的核心作用

Bridge（桥接层）模块是 Claude Code 系统架构的心脏，它的核心作用可以总结为以下几点：

1. 沙盒隔离与多端协同：将终端 UI 渲染（基于 ink）与实际执行大语言模型请求及工具调用的环境分离开来。这使得 Claude Code 不仅可以在本地执行，还能够将计算和文件操作无缝转移到远程容器或云端服务器上运行。
2. 连接保持与容错断线重连：当用户在网络不稳定或终端意外关闭的情况下，Bridge 层通过长连接（WebSocket）、心跳检测和轮询机制（pollConfig.ts）确保会话状态不丢失，支持 claude remote-control --session-id 等命令重连会话。
3. 并发任务编排与容量控制：通过 sessionRunner.ts 进行多个并发子进程的分配（支持单会话、Git Worktree 隔离会话等多种模式 SpawnMode），结合背压控制（flushGate.ts）防止大规模日志导致内存溢出。
4. 零信任安全与设备校验：结合 jwtUtils.ts、workSecret.ts 和 trustedDevice.ts 等模块，实现了精细的权限校验、动态 Token 刷新以及可信设备认证机制，防止提权攻击。

报告两万字深度解析结构大纲

为了彻底解构这套精妙的底层系统，本报告将分为以下七大章节，逐步为您进行源码级别的拆解。以下是这份长篇技术报告的完整大纲：

第一章：架构概览与进程拓扑结构 (Architecture & Topology)

• 1.1 设计哲学：为何引入 Bridge 模式？阻塞 UI 线程的痛点与解法
• 1.2 进程与线程模型：主进程、Daemon 进程与 Runner 子进程
• 1.3 多工作模式支持 (SpawnMode)：Single-Session, Worktree, 与 Same-Dir 模式详解
• 1.4 依赖注入与生命周期管理：Bridge 的启动与安全销毁 (registerCleanup)

第二章：REPL Bridge 与核心通信层实现 (Transport Layer)

• 2.1 BridgeCoreParams 与环境上下文注入 (replBridge.ts)
• 2.2 ReplBridgeTransport 抽象层：双栈通信协议设计
  • 2.2.1 V1 与 V2 传输层的兼容与演进 (replBridgeTransport.ts)
  • 2.2.2 WebSocket 拦截与混流传输 (HybridTransport)
• 2.3 核心通信引擎 remoteBridgeCore.ts 与 bridgeMain.ts
  • 2.3.1 连接状态机：Ready -> Connected -> Reconnecting -> Failed
  • 2.3.2 轮询策略与退避算法 (BackoffConfig) 深度解析
• 2.4 SDK 与 Bridge 的消息映射机制

第三章：会话生命周期与 Runner 机制 (Session Execution Sandbox)

• 3.1 Code Session 的全局状态机模型
• 3.2 sessionRunner.ts：子进程拉起与执行环境保护
  • 3.2.1 ChildProcess 创建与跨平台兼容（Windows vs Unix）
  • 3.2.2 环境变量隔离（envLessBridgeConfig.ts）与安全工作目录分配 (safeFilenameId)
• 3.3 会话控制：启动、中断、与异常退出收尾机制 (createSession.ts, codeSessionApi.ts)
• 3.4 孤儿进程感知与自我修复收割策略

第四章：消息协议定义与流转控制 (Messaging & Flow Control)

• 4.1 核心数据结构解析 (types.ts)
  • 4.1.1 WorkData, WorkResponse 与 BridgeConfig 接口设计
  • 4.1.2 SessionActivity：粒度化行为追踪（工具调用、文本输出等）
• 4.2 指令序列化与协议编解码 (bridgeMessaging.ts, inboundMessages.ts)
• 4.3 数据流时序链路分析 (Sequence Analysis)
  • 4.3.1 客户端请求派发与 Runner 接收
  • 4.3.2 UI 异步状态回传与状态归并 (bridgeStatusUtil.ts, bridgeUI.ts)
• 4.4 流量控制与背压机制 (flushGate.ts)
  • 4.4.1 高并发 LLM 吐字情况下的内存防溢出策略
  • 4.4.2 队列聚合与丢包容忍度设计

第五章：权限控制、设备信任与安全沙箱 (Security & Auth)

• 5.1 API 层与设备信任链 (trustedDevice.ts)
  • 5.1.1 设备的注册与校验
  • 5.1.2 应对未授权抓包或重放攻击的策略
• 5.2 JWT 会话凭据与生命周期维护 (jwtUtils.ts)
  • 5.2.1 动态 Token 刷新的 Scheduler 机制
• 5.3 动态指令拦截与行为放行 (bridgePermissionCallbacks.ts)
  • 5.3.1 控制请求 control_request 与 can_use_tool 的交互式审批逻辑
• 5.4 workSecret 与密钥泄露防范 (workSecret.ts)

第六章：资源调度、唤醒与故障注入容错 (Resource Management & Resilience)

• 6.1 轮询与唤醒的协作机制 (pollConfig.ts, capacityWake.ts)
  • 6.1.1 动态轮询间隔配置（getPollIntervalConfig）
  • 6.1.2 CapacitySignal 的触发与资源回收
• 6.2 断线重连与幂等性注册设计 (Idempotent Registration)
• 6.3 异常捕获与诊断追踪 (debugUtils.ts, bridgeDebug.ts)
  • 6.3.1 故障注入测试 (Fault Injection) 机制分析
  • 6.3.2 FatalError 的界定与优雅降级退出

第七章：架构评估与二次开发指南 (Evaluation & Expansion)

• 7.1 现有 Bridge 架构的优雅之处与工程亮点总结
• 7.2 系统性能瓶颈探讨与优化展望
• 7.3 扩展实践：如何基于本架构新增自定义 Remote Runner（例如直连私有云物理机）
• 7.4 总体总结与开发者寄语

---

第一章：架构概览与进程拓扑结构 (Architecture & Topology)

1.1 设计哲学：为何引入 Bridge 模式？

在典型的 CLI 应用程序中，终端 UI 的渲染逻辑和底层的计算逻辑通常在同一个主线程中执行。然而，对于像 Claude Code 这样需要执行大量 I/O 操作（大文件读写、全代码库检索）、长耗时任务（如拉起复杂的 Bash 脚本或长时间编译），并不断流式处理大语言模型 (LLM) 响应的系统来说，将它们耦合在一起会导致致命的阻塞问题。

Node.js 是单线程事件循环模型。如果 grep 操作或者构建工作在主线程同步进行，基于 ink 的 React 终端渲染引擎就会卡死，导致用户无法中止操作，屏幕进度条停止转动。

因此，Claude Code 的设计者引入了 Bridge 架构。这套架构的核心哲学是：UI 进程只负责交互、状态展现和拦截审批，所有“脏活累活”通过 IPC/RPC 交由隔离的 Runner 子进程或远端服务器执行。

1.2 进程与线程模型：主进程、Daemon 进程与 Runner 子进程

Claude Code 的跨进程模型实际上远比简单的 spawn 复杂，它隐含了一种 C/S 或 Server-Worker 拓扑：

1. UI 主进程 (REPL / CLI)：负责展示终端界面，获取用户输入，管理 API 鉴据，并与 Bridge 层通信。
2. Bridge 控制层 (Daemon/Server)：可以通过 claude remote-control 作为独立的守护进程启动，它连接到 Claude 的中央服务端轮询任务（Polling）。
3. Session Runner (Worker 子进程)：实际加载 LLM 代理上下文、执行命令的实体。由 Bridge 控制层根据容量或任务请求动态拉起 (sessionRunner.ts)。

这种设计使得 Claude Code 天然具备成为“远程云端 Agent”的能力。本地 UI 和实际干活的 Agent 完全解耦。

1.3 多工作模式支持 (SpawnMode)

通过对 src/bridge/types.ts 的深入阅读，可以发现 Bridge 架构对并发子进程（Sessions）的工作区管理有着精妙的设计。

/**
 * How `claude remote-control` chooses session working directories.
 * - `single-session`: one session in cwd, bridge tears down when it ends
 * - `worktree`: persistent server, every session gets an isolated git worktree
 * - `same-dir`: persistent server, every session shares cwd (can stomp each other)
 */
export type SpawnMode = 'single-session' | 'worktree' | 'same-dir'

• single-session (单例模式)：经典本地交互模式，在当前执行目录 (cwd) 启动一个会话，结束即销毁。
• worktree (沙盒/多租户隔离模式)：极致的并发工程设计。每个并行启动的任务会被分配一个隔离的 git worktree。这保证了不同 Agent 并行改写代码时，不会发生文件锁冲突或互相覆盖。
• same-dir (竞态模式)：所有的并行 Session 共享同一个工作目录。

---

第二章：REPL Bridge 与核心通信层实现 (Transport Layer)

通信引擎 (Transport Layer) 是整个体系中最关键的部分。在 src/bridge/replBridgeTransport.ts 和 remoteBridgeCore.ts 中，我们看到了优雅的“双栈”底层协议实现。

2.1 核心类图：双栈传输与状态控制 (Mermaid)

classDiagram
    class ReplBridgeTransport {
        <<interface>>
        +write(message: StdoutMessage) Promise~void~
        +writeBatch(messages: StdoutMessage[]) Promise~void~
        +close() void
        +isConnectedStatus() boolean
        +getStateLabel() string
        +connect() void
        +getLastSequenceNum() number
    }

    class HybridTransport {
        +write()
        +read()
    }

    class SSETransport {
        +connect()
        +onData()
    }

    class CCRClient {
        +writeEvent()
        +reportState()
    }

    class EnvLessBridgeParams {
        <<interface>>
        +baseUrl: string
        +orgUUID: string
        +title: string
    }

    ReplBridgeTransport <|.. HybridTransport : V1 Adapter
    ReplBridgeTransport <|.. SSETransport : V2 Adapter (Reads)
    ReplBridgeTransport <|.. CCRClient : V2 Adapter (Writes)

    BridgeCoreHandle "1" *-- "1" ReplBridgeTransport : uses

2.2 ReplBridgeTransport 抽象层：双栈通信协议设计

在 src/bridge/replBridgeTransport.ts 中，代码揭示了 Claude Code 正在经历一次底层协议的重大升级 (V1 -> V2)：

• V1 协议 (HybridTransport)：使用 WebSocket (WS) 处理读操作（服务端到客户端的指令流），使用 POST 请求 (Session-Ingress) 处理写操作。
• V2 协议 (CCR v2)：转向 Server-Sent Events (SSE) 进行下行数据流，并使用专门的 CCRClient (POST /worker/events) 进行上行汇报。

源码注释极为清晰地说明了这一点：

/**
 * Transport abstraction for replBridge. Covers exactly the surface that
 * replBridge.ts uses against HybridTransport so the v1/v2 choice is
 * confined to the construction site.
 *
 * - v1: HybridTransport (WS reads + POST writes to Session-Ingress)
 * - v2: SSETransport (reads) + CCRClient (writes to CCR v2 /worker/*)
 */
export type ReplBridgeTransport = {
  write(message: StdoutMessage): Promise<void>
  // ...

为什么从 WebSocket 转向 SSE + POST 组合？ WebSocket 虽然是全双工的，但在复杂的企业级网关、代理和负载均衡器下，长连接维护成本高，且容易被意外掐断或静默 Drop 掉。SSE (Server-Sent Events) 基于纯粹的 HTTP，对各类反向代理更加友好，非常适合 LLM “逐字吐出”这样的单向流式下发场景。而客户端往服务端发送的大多是明确结构化的状态更新或工具调用结果，通过无状态的 RESTful POST 发送更为稳妥，更易于做重试和背压。

2.3 remoteBridgeCore.ts 与无环境沙盒 (Env-Less)

这部分文件实现了一个非常极客的设计。传统的 Bridge 往往需要完整的注册、轮询、调度机制（Environments API）。但对于单纯的 REPL (交互式控制台)，这显得太重了。

initEnvLessBridgeCore 跳过了 environment 的概念，直接与 Session 通信：

// 摘自 remoteBridgeCore.ts 注释
//   1. POST /v1/code/sessions              (OAuth, no env_id)  → session.id
//   2. POST /v1/code/sessions/{id}/bridge  (OAuth)             → {worker_jwt...}
//   3. createV2ReplTransport(worker_jwt, worker_epoch)         → SSE + CCRClient

这种直连模式降低了本地终端交互的延迟。

2.4 断线重连与退避算法 (BackoffConfig) 深度解析

分布式系统中最头疼的是网络抖动。在 bridgeMain.ts 中，我们看到了严谨的指数退避重连算法配置：

export type BackoffConfig = {
  connInitialMs: number
  connCapMs: number
  connGiveUpMs: number
  generalInitialMs: number
  generalCapMs: number
  generalGiveUpMs: number
}

const DEFAULT_BACKOFF: BackoffConfig = {
  connInitialMs: 2_000,
  connCapMs: 120_000, // 2 minutes (重试间隔上限)
  connGiveUpMs: 600_000, // 10 minutes (最终放弃阈值)
  generalInitialMs: 500,
  generalCapMs: 30_000,
  generalGiveUpMs: 600_000, // 10 minutes
}

当 pollForWork 或长连接失败时，Bridge 不会进行疯狂的紧循环重试（这会导致 CPU 暴涨并可能被服务器 WAF 封禁）。它会在 connInitialMs (2秒) 开始，每次失败后乘以一定系数，直到达到 connCapMs (2分钟)，最后如果连续断网超过 10 分钟，则宣布 Failed 并向 UI 抛出错误。

为了应对系统休眠唤醒（例如笔记本合盖）：

function pollSleepDetectionThresholdMs(backoff: BackoffConfig): number {
  return backoff.connCapMs * 2
}

系统会对比前后两次 Tick 的时间差。如果时间差大于 2 倍的上限（4分钟），系统会意识到这并不是网络卡顿，而是物理机休眠了。此时系统会重置网络错误计数器，避免从休眠恢复时由于积累的 Error Budget 被直接判定为断线。这种极具工程经验的处理令人拍案叫绝。

---

第四章：消息协议定义与流转控制 (Messaging & Flow Control)

4.1 核心数据结构解析 (types.ts)

为了确保服务端 (Web/Backend) 和客户端执行沙箱 (Bridge Worker) 之间通信不出错，Claude Code 在 src/bridge/types.ts 抽象了高度规范化的数据结构。

这里最值得注意的是 WorkResponse 和 SessionActivity：

export type SessionActivityType = 'tool_start' | 'text' | 'result' | 'error'

export type SessionActivity = {
  type: SessionActivityType
  summary: string // e.g. "Editing src/foo.ts", "Reading package.json"
  timestamp: number
}

由于远端可能同时拉起数十个并发任务，CLI 进程不可能把所有执行的底层日志都打满屏幕。SessionActivity 机制就是为了在本地 UI 状态栏渲染一句人类可读的 summary（如 "Searching src/*.ts"），既节省了传输带宽，又提升了交互体验。

4.2 指令序列化与协议编解码 (bridgeMessaging.ts)

并非本地执行的所有操作都需要同步到远端，也并非远端发来的所有消息都应该直接推给终端执行。bridgeMessaging.ts 充当了“路由器”。

export function isEligibleBridgeMessage(m: Message): boolean {
  // Virtual messages (REPL inner calls) are display-only 
  if ((m.type === 'user' || m.type === 'assistant') && m.isVirtual) {
    return false
  }
  return (
    m.type === 'user' ||
    m.type === 'assistant' ||
    (m.type === 'system' && m.subtype === 'local_command')
  )
}

通过 isEligibleBridgeMessage 拦截器，应用主动过滤了如代码格式化进度、临时终端输出等纯本地显示性质的消息，大幅减少了向远端发送的无效 HTTP 请求。

同时，针对网络乱序或重发，handleIngressMessage 通过维护 BoundedUUIDSet (近期收到的消息 ID 集合) 来防止“历史消息回放导致状态突变”。

4.3 数据流时序链路分析 (Sequence Analysis)

一幅典型的端到端指令流转时序图如下所示：

sequenceDiagram
    autonumber
    actor User as 开发者终端
    participant UI as Claude REPL UI
    participant Bridge as Bridge Transport
    participant Server as Claude.ai Backend
    participant Runner as Remote Worker

    User->>UI: 输入请求: "帮我重构这个文件"
    UI->>Bridge: isEligibleBridgeMessage? (Yes)
    Bridge->>Server: HTTP POST /events (SDKMessage)
    Server->>Runner: SSE 下发执行请求
    Runner->>Server: 上报 SessionActivity (tool_start: "Editing...")
    Server->>Bridge: SSE 状态同步
    Bridge->>UI: 拦截并抽取文本提取标题 (extractTitleText)
    UI->>User: 状态栏显示 "Editing..."
    Runner->>Server: 提交代码更改
    Server->>Bridge: 成功信号
    Bridge->>UI: 渲染更新结果

4.4 流量控制与背压机制 (flushGate.ts)

当处理长对话或者初始化连接时，如果历史消息流没有发送完毕，新产生的日志如果强行插入，会导致服务端大语言模型的上下文发生时序错乱。

为此，作者引入了精巧的 FlushGate：

export class FlushGate<T> {
  private _active = false
  private _pending: T[] = []

  enqueue(...items: T[]): boolean {
    if (!this._active) return false
    this._pending.push(...items)
    return true
  }

  end(): T[] {
    this._active = false
    return this._pending.splice(0)
  }
}

在建立连接并主动拉取/同步历史消息（flush）期间，FlushGate 处于活跃 (active=true) 状态。此期间本地产生的任何新操作、新消息全部通过 enqueue() 被塞入 _pending 队列。直到历史完全回放且确认服务端对齐后，调用 end()，之前排队的队列瞬间放闸（Drain），完美解决了竞争条件和异步时序问题。

---

第五章：权限控制、设备信任与安全沙箱 (Security & Auth)

在允许外部服务器远程唤起本地 shell 和文件系统的架构下，安全防线一旦崩溃，就会造成极其严重的代码泄露甚至物理机控制权丧失。

5.1 API 层与设备信任链 (trustedDevice.ts)

为了确保“只有我授权的受信任机器才能作为 Worker 执行代码”，系统利用了一个强认证机制：

const TRUSTED_DEVICE_GATE = 'tengu_sessions_elevated_auth_enforcement'

export async function enrollTrustedDevice(): Promise<void> {
    // ... 
    response = await axios.post(
      `${baseUrl}/api/auth/trusted_devices`,
      { display_name: `Claude Code on ${hostname()} · ${process.platform}` }
    )
    getSecureStorage().update({ trustedDeviceToken: response.data.device_token })
}

安全等级跃升：在服务端，这类 Bridge Sessions 会被标记为 SecurityTier=ELEVATED。如果 CLI 的终端未经过 POST /auth/trusted_devices（必须在登录后 10 分钟内完成，防止被盗用的老 Session 恶意注册），或者没有附带存在操作系统安全芯片（Keychain/Secure Storage）中的 Token，服务端将直接拒绝建立 Bridge 通道。这掐断了简单的 Token 窃取重放攻击链路。

5.2 JWT 会话凭据与生命周期维护 (jwtUtils.ts)

会话使用 JWT (JSON Web Token) 进行授权。为了防止执行长时构建任务（例如耗时数小时的编译）时因为 Token 过期而中断，jwtUtils.ts 实现了非常优雅的抢占式 Token 刷新。

export function createTokenRefreshScheduler(...) {
  // 解析 exp claim
  const expiryDate = new Date(expiry * 1000).toISOString()
  const delayMs = expiry * 1000 - Date.now() - refreshBufferMs

  // 提前 5 分钟 (refreshBufferMs) 触发续约
  const timer = setTimeout(doRefresh, delayMs, sessionId, gen)
}

它会在解析出 JWT 过期时间后，设置一个定时器，在真正过期前的 5 分钟安全缓冲期内，透明地发去新请求换取新的 ingress_token，再热注入到通信层，整个过程用户完全无感知。

5.3 workSecret 与密钥解析 (workSecret.ts)

对于云端分发给沙箱环境执行的任务，它的安全屏障是 WorkSecret 凭证：

export function decodeWorkSecret(secret: string): WorkSecret {
  const json = Buffer.from(secret, 'base64url').toString('utf-8')
  const parsed = jsonParse(json)
  if (parsed.version !== 1) {
    throw new Error('Unsupported work secret version')
  }
  // 强校验 ingress_token 存在
  return parsed as WorkSecret
}

在建立 Bridge 之前，配置与指令均被打包进 base64url 格式的 secret 字符串下放。这一机制保障了环境变量和令牌的安全交接。如果不带上正确的版本头及包含令牌，系统会在反序列化阶段立即阻断，杜绝畸形协议攻击。

---

第六章：资源调度、唤醒与故障注入容错 (Resource Management & Resilience)

在这部分，系统展现了如何稳定维护数十个子进程，以及如何在资源耗尽与恢复之间从容切换。

6.1 轮询与唤醒的协作机制 (pollConfig.ts, capacityWake.ts)

长连接维护时通常面临一个两难的问题：如果服务端迟迟没有派发任务，频繁的心跳轮询（Polling）会极大浪费客户端与服务端的 CPU 及带宽资源；但如果轮询间隔过长，任务派发的实时性又会很差。

在 pollConfig.ts 中，使用 Zod 定义了一套由 GrowthBook 控制的云端下发轮询策略：

const pollIntervalConfigSchema = lazySchema(() =>
  z.object({
      poll_interval_ms_not_at_capacity: z.number().int().min(100),
      poll_interval_ms_at_capacity: z.number().int().refine(v => v === 0 || v >= 100),
      // ...
  })
)

其中最值得注意的是“空闲” (not_at_capacity) 与“满载” (at_capacity) 两种状态的不同时间策略。如果 Worker 并发数已经满了，Bridge 就会自动切换到慢速的休眠心跳（poll_interval_ms_at_capacity）。

但一旦某个任务执行完毕，腾出空位了怎么办？如果此时处于长达两分钟的“满载休眠期”，新任务岂不是被延迟两分钟？此时 capacityWake.ts 登场：

export function createCapacityWake(outerSignal: AbortSignal): CapacityWake {
  let wakeController = new AbortController()

  function wake(): void {
    wakeController.abort() // 主动打断当前的休眠
    wakeController = new AbortController() // 重置状态
  }
  // ...
}

通过 AbortController 拦截器，它能在任何子任务（Session）退出的瞬间，强行中断“满载休眠”的心跳倒计时，使得主引擎立刻发起一次新的拉取任务请求，保证了任务调度的极致延迟。

6.2 异常捕获与诊断追踪 (bridgeDebug.ts)

为了测试如此复杂的断网重连、401/403 Token 失效、以及 500 内部服务错误，开发团队实现了一个自带的故障注入 (Fault Injection) 模块：

export function wrapApiForFaultInjection(api: BridgeApiClient): BridgeApiClient {
  function throwFault(fault: BridgeFault, context: string): never {
    if (fault.kind === 'fatal') {
      throw new BridgeFatalError(`[injected] ${context} ${fault.status}`, fault.status)
    }
    throw new Error(`[injected transient] ${context} ${fault.status}`)
  }
  // ...
}

通过特殊的控制台命令 /bridge-kick，测试人员可以直接对底层的 Axios 请求进行 Mock 劫持，将下一次的 pollForWork 或 heartbeatWork 请求模拟成 Fatal（比如模拟后端判定当前工程环境已经被销毁的 404）或者 Transient（比如短暂的 503 网关无响应）。这种深埋于主代码内部的测试桩，体现了高健壮性系统的工程成熟度。

---

第七章：架构评估与二次开发指南 (Evaluation & Expansion)

7.1 架构评估与工程亮点总结

综合这数万字的源码阅读，Claude Code 的 Bridge 架构可以用四个词来概括：安全、解耦、健壮、精妙。

• 优雅之处：彻底分离 UI 线程与计算进程，使用双栈 (WS + SSE/POST) 保障通信。CapacityWake 中断和 FlushGate 背压缓存，使得交互极其丝滑流畅。
• 健壮性：不仅通过指数退避机制解决了网络断开重连的问题，还神奇地考虑了“物理机长时间休眠”的时间差计算。同时自建了 Fault Injection 测试框架。

7.2 二次开发与扩展实践：对接私有云 Runner

这套架构的设计完全具备“接入其他远端计算节点”的潜力。如果在未来需要扩展（例如，不拉起本地的子进程，而是通过 SSH 协议拉起远程物理机的 Runner）：

1. 修改 sessionRunner.ts： 我们需要新实现一个 RemoteSSHSpawner 类，实现 SessionSpawner 接口。在这个类中，spawn 函数不再使用 child_process.spawn('claude')，而是使用 spawn('ssh', ['user@remote_host', 'claude ...'])。
2. 环境变量注入： 将原本分配给本地的 envLessBridgeConfig 通过 Base64 编码，以环境变量的形式传递到 SSH 的远端机器中。远端的 claude 进程作为 Daemon 被拉起，并通过它自己的 ReplBridgeTransport 连接回 Claude 后端，此时本地的 CLI 就完完全全变成了一个“壳（Thin Client）”。

7.3 总体总结

Claude Code 不仅仅是一个 CLI 工具，它底层藏着一套具备工业级可靠性的分布式任务调度与长连接保活框架。这种架构设计对编写跨端工具、甚至是后续研发我们自己的高并发 Agent 引擎具有极高的参考价值。这套源码完美展示了 TypeScript/Node.js 在处理复杂异步并发模型、资源锁和流式通信时的极限威力。