这段代码似乎是把字符串"Alice"放进了变量user_name。运行结果不是["Alice"]如果是一份独立备份，修改它就不应该影响。问题在于，赋值语句并没有复制列表，只是让两个名称关联到了同一个对象。修改函数参数后，调用方的数据也发生了变化。使用字典模板生成记录，多条记录却共享同一个列表。对配置执行了浅拷贝，修改嵌套字段时仍然污染原配置。服务运行一段时间后内存持续增长，却找不到没有释放的变量。

PluginConfigExtensionConfig,同一层级内仍保留稳定动作顺序。1. 按优先级稳定排序2. 对同名 Server 保留最终 Winner3. 收集同 Tier 冲突4. 应用 Disabled Name Veto5. 生成不可变 ResolvedMcpCatalogMcpManagerserveroutcomecontenders因此同名 MCP Server 不是依赖Has

上一篇分析了无交互模式与两套 SDK。这不是重复保存同一份数据。本篇会从源码出发，把这套设计拆开。

上一篇从ToolRouter出发，分析了模型如何看到工具、工具调用如何路由到Handler，以及并行工具为什么仍按调用顺序回填结果。真正的副作用并不会立即发生。三者不能混为一谈。Approved只表示审批通过，不必然表示无沙箱执行。只有当所有解析出的命令段都被显式allow规则覆盖时，才可能让第一次执行直接绕过文件系统沙箱。如果权限配置中存在 denied-read 路径，即使命令已经获得批准，也

Runner 会在运行时 clone capabilities、绑定 live session、构造 sandbox instructions、注入 shell/filesystem tools，然后仍然通过普通。下一篇将继续进入 Sandbox Agent 进阶，重点看 capabilities、memory、远程 sandbox provider 和更细的安全边界。前十五篇已经覆盖了 SDK

中间件可以通过泛型参数扩展状态类型。例如定义了自己的状态 schema（来自 LangGraph，表示该字段在 checkpoint 中不持久化——每次 Agent 调用（run）重新计数，而则在整个会话线程中累积。是所有中间件的基类，定义于types.py@property泛型参数约束说明StateT中间件操作的状态类型，可自定义扩展字段ContextT无约束，默认None运行时上下文类型，通过

当 Claude Code 从个人工具进入团队或企业环境时，最大变化不是安装方式，而是治理方式。个人可以灵活调整权限、插件和工具使用策略；组织则需要统一边界，避免不同开发者的本地设置绕过安全要求。本项目的和给出了两层样例：前者展示托管设置应该如何写，后者展示这些设置如何通过设备管理系统分发。

Codex CLI 表面上是一个终端命令：在项目目录执行codex，输入任务，然后等待它阅读代码、执行命令并修改文件。如果只把它理解成“给大模型套了一层命令行界面”，后续阅读源码会很快遇到困难。这个仓库实际实现的是一套本地 Agent Runtime：它既要连接模型，也要管理会话、上下文、工具、权限、沙箱、扩展、持久化和多个客户端。本篇先不深入某个函数，而是建立一张全局地图。后续每篇课程都会沿着这

),)]);Some(vec!),})使用propertiesrequired三者一致。

Prompt组装请求。input 已经由 ContextManager 维护、截断和规范化tools 已经由 ToolRouter 规划base_instructions 已经在 Session 创建时解析跳过模型摘要跳过远程压缩直接开始新 Context Window当前 Canonical Initial Context并生成一个空消息的检查点。