深入研究
状态管理解析：AppStateStore 里到底保存了什么
Claude Code 不是一次性脚本，而是长期运行界面
只要看 state/AppStateStore.ts，你就会立刻意识到一件事：
Claude Code 绝不是一个“执行一下就退出”的普通 CLI。
它内部维护了大量 UI 与会话态数据，这说明它本质上是一个终端应用。
这里保存的状态远比你想象的多
AppState 里能看到很多类型的信息：
- 当前 settings、model、verbose、状态栏文本
- 工具权限上下文
- 任务列表与前台任务
- MCP 客户端、工具、命令、资源
- 插件启用状态和错误
- 通知队列与 elicitation 队列
- 远程连接状态
- prompt suggestion、thinking、session hooks
- Todo、attribution、file history
- Companion、tmux、browser panel 等界面状态
这已经不是简单的“页面状态”，而是完整运行时状态。
为什么终端程序会需要这么重的状态
因为 Claude Code 不只是显示文本，它还要同时协调很多异步对象：
- 模型响应流
- 工具执行
- 背景任务
- 权限弹窗
- MCP 连接
- 插件刷新
- 远程桥接
- 通知与提示
如果没有统一状态中心，这类系统会非常容易失控。
AppStateStore 的真正作用
可以把它理解为 Claude Code 交互层的总线：
- 上层 UI 从这里读当前状态
- 下层工具和服务往这里写状态变化
- 某些跨模块能力通过它共享会话级信息
也就是说，它不是一个被动数据容器，而是终端应用稳定运转的基础设施。
这也解释了 Claude Code 为什么能做复杂交互
很多高级交互能力，本质上都依赖统一状态管理：
- 同时存在多个任务和前后台切换
- 在 REPL 里显示不同面板
- 远程会话连接状态实时更新
- 插件安装状态可追踪
- MCP 资源、工具、命令动态变化
这些体验的背后，都离不开 AppState 的组织。
小结
AppStateStore.ts 传达出的一个重要信号是：
Claude Code 不是“命令行里的模型调用器”，而是一个状态复杂、交互丰富、长期驻留的终端应用。
理解这一点，很多看似“为什么这里这么重”的设计就都说得通了。