先理解三段式启动：入口装配、会话准备、基础设施初始化
如果不先看清启动链路，后面的查询、权限、MCP、worktree 行为都会显得像“凭空出现”。这套代码最值得注意的不是只有一个入口，而是有一条被明确拆开的启动责任链。
本页回答什么问题
- 为什么启动被拆成
main.tsx、setup.ts、entrypoints/init.ts三层？ - REPL 是在哪里真正被启动的？
- worktree、hooks、tmux、remote 等前置条件在哪一层被处理？
- 为什么这种拆法对冷启动和多运行模式更友好？
启动时序图
这张图展示启动责任如何逐层下沉。重点不是“先后顺序”本身，而是不同初始化类型被有意识地放在不同层。
第一段：src/main.tsx
这是高层装配入口。它负责 profiling 预热、命令和工具注册、模式分流，并决定是进入 REPL、bridge 还是 remote 等运行路径。这里的核心职责不是实现每个子系统，而是把运行条件拼成一个可执行产品。
- 装配命令、工具、MCP、plugins、skills。
- 根据 feature / mode 决定走哪条入口路径。
- 把真正的会话准备和基础设施初始化下沉给后续层。
第二段：src/setup.ts
这层偏“会话准备”而不是“产品功能”。它做 Node 版本检查、UDS messaging、terminal 恢复、setCwd、hook snapshot、文件变更 watcher、worktree 和 tmux 相关准备。这一层的设计说明：作者把“终端环境能不能正确跑起来”视为一等问题，而不是入口顺手带过的副作用。
第三段：src/entrypoints/init.ts
这一层偏“基础设施启用”，包括 settings system、safe env vars、CA 证书、proxy、mTLS、OAuth 补全、remote settings / policy limits 预加载、preconnect、scratchpad 初始化等。它的存在把“产品运行需要的基础设施”从“终端本地环境准备”里分离出来。
REPL 真正是怎样启动的
从入口层继续往下，会进入 src/replLauncher.tsx 和 src/interactiveHelpers.tsx 所组织的渲染路径，再由 src/screens/REPL.tsx 成为长期运行的交互壳。这条路径很重要，因为它解释了为什么 REPL 会拥有比“一个 React 页面”更高的职责密度。
main.tsx 的渲染细节负担，但并没有消除 REPL 作为运行时集成壳的复杂性。三段式启动为什么存在
- 把“进程入口装配”和“会话环境准备”分开，降低主入口的心智负担。
- 把“本地终端条件”与“产品基础设施初始化”分开，方便支持 remote / bridge / enterprise 形态。
- 让 profiling、preconnect、OAuth、policy limits 之类的重操作可以更明确地安排时机。
- 为未来继续新增模式分流保留结构空间。
本页重点文件
src/main.tsx
主入口，产品模式与高层装配中心。
src/setup.ts
会话环境准备层，负责 cwd、hook、worktree、tmux、terminal 恢复等运行前条件。
src/entrypoints/init.ts
基础设施初始化层，负责配置、网络、安全环境变量、OAuth、scratchpad 等。
src/replLauncher.tsx / src/interactiveHelpers.tsx
把入口装配和具体 REPL 渲染/运行路径衔接起来。