启动流程解析：main.tsx 到 REPL 是怎么串起来的

为什么 main.tsx 值得重点看

很多项目的入口文件只是薄薄一层，但 Claude Code 的 main.tsx 明显不是。
从导入规模和初始化动作就能看出来，它承担的是“系统装配器”的角色。

它做的事情至少包括：

• 启动早期性能预热
• 解析命令行参数
• 加载设置、策略和环境变量
• 初始化认证与实验开关
• 收集命令与工具
• 启动交互式 REPL 或其他运行模式

一开头就在抢启动时间

文件最前面的几个 side effect 很有代表性：

• profileCheckpoint
• startMdmRawRead()
• startKeychainPrefetch()

这说明 Claude Code 团队已经把启动性能当成正式问题来优化。
也就是说，入口文件不只是“能跑起来”，而是在尽量把一些 I/O 提前并行化。

对应源码片段

profileCheckpoint('main_tsx_entry');
import { startMdmRawRead } from './utils/settings/mdm/rawRead.js';
startMdmRawRead();
import { ensureKeychainPrefetchCompleted, startKeychainPrefetch } from './utils/secureStorage/keychainPrefetch.js';
startKeychainPrefetch();

这段代码的重点不是语法，而是时机：

• profileCheckpoint 先打点
• MDM 读取尽早启动
• keychain 预取尽早启动

这说明入口层是在主动缩短后续等待时间。

为什么入口层会有这么多 side effect

从一般编码习惯看，入口层副作用越少越好。
但 Claude Code 这里恰恰相反，因为它面对的是一个真实 CLI 产品：

• 启动时间要快
• 配置必须尽早生效
• 某些系统状态要在后续导入前可用

所以这里不是“写得随意”，而是明确在为运行时体验服务。

它先决定“这次启动是什么会话”

启动后要先弄清几个问题：

• 当前是不是交互模式
• 有没有远程会话或桥接模式
• 要不要恢复旧会话
• 模型、权限、提示风格、工作目录是什么

这些信息会影响后续整个系统装配结果。
所以 main.tsx 的很多逻辑，实际上是在决定“这次 session 的运行形态”。

命令、工具、设置是在这里汇总的

从导入关系能看出来，main.tsx 会把几类核心资源拉到一起：

• getCommands() 获取命令系统
• getTools() 获取工具集合
• getSystemContext() / getUserContext() 获取上下文
• 各种设置与 feature gate 决定哪些能力启用

也就是说，真正把 Claude Code 拼装成一个可运行系统的地方，不在某个单独 service，而就在入口层。

对应源码片段

import { getSystemContext, getUserContext } from './context.js';
import { filterCommandsForRemoteMode, getCommands } from './commands.js';
import { getTools } from './tools.js';
import { launchRepl } from './replLauncher.js';

这几行代码几乎已经把入口层的主线交代清楚了：

• 先拿上下文
• 再拿命令
• 再拿工具
• 最后进入 REPL

也就是说，REPL 看到的不是“裸模型”，而是已经装配好的运行时。

入口层最像什么

如果一定要类比，main.tsx 很像后端系统里的“应用装配根”：

• 它不负责所有细节实现
• 但负责决定细节如何被拼起来
• 任何关键子系统最终都要在这里接上线

它不是只启动 REPL，还会先初始化外部能力

源码里还能看到很多外围系统在入口层就被拉起：

• MCP 相关初始化
• LSP Server Manager 初始化
• 插件与技能初始化
• 远程会话配置
• 遥测与限制策略

原因也很直接：
这些能力都可能影响当前 session 的工具清单、命令清单和界面状态，所以必须在进入主循环前先准备好。

对应源码片段

import { initializeLspServerManager } from './services/lsp/manager.js';
import { getMcpToolsCommandsAndResources, prefetchAllMcpResources } from './services/mcp/client.js';
import { initBuiltinPlugins } from './plugins/bundled/index.js';
import { initBundledSkills } from './skills/bundled/index.js';

这组导入说明入口层天然就是能力汇流点。
LSP、MCP、插件、Skills 这些都不是后面临时发现，而是在会话建立阶段就已经纳入考虑。

REPL 只是表层，真正重要的是“运行态装配完成”

很多人看到终端界面，直觉会把 Claude Code 当成一个 React Ink 程序。
这个理解只对一半。

REPL 当然重要，但它更像是表现层。
真正关键的是：在 REPL 出现之前，系统已经把下面这些东西准备好了：

• 会话设置
• 模型选择
• 工具集合
• 命令集合
• 上下文数据
• MCP / LSP / 插件状态
• AppState 初始值

因此 REPL 并不是起点，而是“系统已经装配完成后的交互外壳”。

从用户视角看，它的启动链路是什么

启动流程可以粗略理解为 4 步

入口预热 -> 配置与环境解析 -> 能力装配 -> 进入交互或执行模式

如果把它展开一点，就是：

1. 先做性能预热和必要的早期副作用
2. 解析 CLI 参数、加载 settings、策略和环境
3. 初始化命令、工具、上下文、MCP、LSP、插件、Skills
4. 根据模式决定启动 REPL、恢复会话、远程连接或非交互执行

从源码阅读角度，这篇之后该看什么

理解了启动层后，最自然的下一篇就是 QueryEngine.ts。
因为入口层解决的是“怎么启动”，而 QueryEngine 解决的是“启动之后怎么持续推进任务”。

阅读这一层时要关注什么

看 main.tsx，不建议陷入每一段细节。
更应该关注的是：

• 哪些初始化属于“全局能力”
• 哪些初始化会影响当前 session
• 哪些能力是通过 feature flag 控制的
• 哪些结果最终流向 REPL 或 QueryEngine

只要抓住这四点，入口层就会变得很清楚。

小结

main.tsx 的价值，不在于它实现了什么具体业务，而在于它回答了一个更重要的问题：

Claude Code 在真正开始和你对话前，到底把哪些能力装进了这次会话里？

理解了启动流程，后面看主循环和工具系统就会轻松很多。