命名 scope。 /codex login --scope <名> 会在 <homesRoot>/codex@<名> 里另开一份作用域目录:目录建立时自动跑同一份 config.toml provision(把凭据存储钉在文件而非 macOS keychain),因此该 scope 的登录落在它自己的 auth.json 里。带 scope 的委派用它跑 codex exec、把 rollout 写进它、从它回读;只走 exec——常驻 app-server 绑的是缺省作用域目录。

bundle 组成。 patch 注册 codex harness(CODEX_HOME 作用域目录、PTY 登录、rollout 文件会话记录),并把 subagent_codex 工具挂到 profile 根——官方 preset 的同名行本就 disabled: true,patch 再禁一次,社区安装永远不会注册出两个 subagent_codex;刻意在自有 preset 层重新启用官方行的用户会得到响亮的重名冲突,按设计必须二选一。codex-local provider 在该作用域目录下 spawn codex exec(live 未启用时的一次性驱动)。浏览器半部分随本包 ./client 提供:Codex 设置卡组合家族 core 的共享 ProviderAuthBlock,独立安装落在 Plugins 页的包详情视图(plugins.bundle.config,按包名派发),作为家族 bundle 成员安装落在 bundle 详情页的行级配置入口(plugins.row.config),0.1.5 落在 设置 → 插件 → 插件配置(settings.plugin.item,按设置命名空间派发);卡片写入经绑定的 settingsScope 热生效,不用重载。core 本身来自声明为依赖的 @khorsheed/dsh-local-agent。

登录与凭据。 /codex login 经宿主 subprocess seam 在伪终端里跑 codex login——CLI 自己起 localhost 回调服务并打开浏览器,这是第一类流程;命令回复附带从输出里抓取的授权 URL 作兜底链接,CLI 追问 code 时用户以 /codex code <code> 粘贴(写入子进程 stdin)。完成由监听作用域目录的凭证 watch 判定:auth.json 出现且时间戳新于 watch 起点——残留的旧凭证不会被误认成新登录。无浏览器的远程终端可以手动以 CODEX_HOME 指向作用域目录跑 codex login --device-auth,凭据落在同一份 auth.json。首次启动写入一份最小 config.toml,固定 cli_auth_credentials_store = "file"——Codex 默认的 auto 会解析到 macOS keychain,把凭据泄漏到作用域目录之外并使本包的 auth.json 存在性检查失效;已存在的 config 保持不动。/codex logout 删除作用域 auth.json,之后重新登录即可换账号。

会话记录。 /codex sessions 列出作用域目录的 sessions/YYYY/MM/DD/rollout-*.jsonl 文件——仅本插件委派产生的会话,绝不含你的私人会话。会话头部的记录入口(家族 core 的客户端提供)把同一份列表收窄到 workDir 与当前会话 cwd 一致的记录。

回读与 cwd 覆盖。 每轮 settle 后,provider 从本轮自己的 rollout 文件里回读三件事,随 settled 进度事件上报并合并进 delegations.jsonl:模型(turn_context.payload.model——codex 0.144.0 的 exec 流事件根本不带 model,rollout 是唯一权威;按本轮时间窗过滤,resume 线程里先前轮次的模型不会被误读)、CLI 版本(session_meta.payload.cli_version——服务本轮的那个 codex build 自己写下的,比事后探测可执行文件更准)、以及非正常结束时流里缺失的 token 用量(最后一条 token_count)。取不到即缺位,绝不猜测。

工具调用计数。 每轮 settle 时,provider 顺带数出本轮的工具调用,随 settled 进度事件上报(toolCalls: { count, byName })。计数只来自流解析已经走过的 item.completed 分支,不新增任何解析路径:command_execution、web_search_call、file_change、function_call 各记一次,function_call_output 是结果、不计。byName 的键是 codex 自己的 item 类型(command_execution),不是镜像卡片上的显示名(Bash)——记的是 CLI 怎么叫这件事。本轮一份,绝不累计;一次都没调用就整个字段缺位(缺席 ≠ 0)。实测:一轮「列目录并统计文件数」回读 {count: 1, byName: {command_execution: 1}},两条命令的一轮回读 {count: 2}。

定位与扫描两处都按并发校准过。turn_context 是 codex 在回合开始时写的,所以一轮里之后产生的事件一多就会把它挤出文件尾——只扫尾部会读回 null(一次真实评测跑就是这么丢的:38 KB 的 smoke 轮读得到,100–500 KB 的正式格读不到),因此尾部扫不到就再做一次有界的整文件读。定位则在 threadId 之外把本轮 cwd 也算进去:并发委派会让多个格的文件落进同一个时间窗,session_meta.payload.cwd 才是区分它们的字段;窗口里有候选却没有一个对得上本轮目录时,宁可什么都不报也不报邻居那一轮(窗口里只有一个候选除外——那是路径写法差异,不是歧义)。编排器还可以经门面 DelegationCallOptions.cwd 给本轮指定工作目录(记录进 cwd 字段);resume 轮解析出的目录若与首轮记录不一致,进程启动前即 fail loud——CLI 会话延续的是首轮所在目录的上下文。

容器内委派。 编排器可以经门面 DelegationCallOptions.exec({ container, workdir, env? })让本轮跑在一个已取得的容器里:argv 变成 docker exec -w <workdir> [-e NAME…] <container> codex exec …,其余(流解析、settle、rollout 回读、记录)逐字节不变。env 必须给出容器内的 CODEX_HOME,且它应当是宿主作用域目录的 rw bind 挂载点——rollout 回读读的是宿主那份文件。容器轮固定走 exec 一次性驱动(长驻 app-server 是宿主进程),且不声明成员桥(宿主 unix socket 进不去容器)。实测:eval-env:pinned 单元里一次「回答 2+2」settle 为 completed,输出 4,observedModel 从容器写进宿主作用域目录的 rollout 里回读为 gpt-5.6-sol。

续聊(resume)。 家族工具(@khorsheed/dsh-local-agent-tool-subagent)在官方 description/prompt 子集上增加可选 resume 参数。首次委派的结果文本自述句柄(追问请带 resume="<childSessionId>");后续轮次传回它即在同一个 dsh 子会话里继续同一个 codex 线程(codex exec --json resume <thread_id>),按轮记账。句柄只从 resume 参数读取,localAgent registry 仅对记录该委派的同一 parent 会话与 provider 解析——伪造句柄在任何 CLI 进程启动前就被拒绝。

事件流镜像。 子代理会话按顺序镜像 codex exec --json 事件流:reasoning → 推理块、agent_message → 回复文本、command_execution/web_search_call/function_call_output → 工具行([工具 Bash] <command> → output),file_change → ApplyPatch 卡(逐 change 列出 kind 与路径),function_call(如 multi-agent 的 wait)→ 同名工具卡、结果由 function_call_output 并入;最终 agent_message 作为运行输出,当轮用量挂在最后一条镜像的 assistant 消息上。续聊轮各自追加自己的 turn,不会重复。中止会让工具结果立即 settle,并保留已收到的事件与用量。

模型体验。 每次委派都是委派 Session 工作区内一个全新的一次性 codex exec 进程。父级只提交任务文本、只看到最终回答或精确错误——Codex 的评论、工具活动、工作区 diff 不会跨进父级会话,子会话 token 也永不进入父级上下文。

长驻驱动(live: true)。 替代每轮 spawn:成员首轮委派拉起一个常驻 codex app-server --stdio 进程(同 scoped home、同 -c 成员桥声明),创建持久线程(thread/start,ephemeral: false),之后每轮 = 向活着的 runtime 发 turn/start;item/completed 事件即时折进子会话(与 exec 共享同一 CodexTranscriptLine 折叠与 append 核,最后一行留置到 turn/completed 以挂用量),cancel 落地为 turn/interrupt——进程不死、线程可续。审批类 server→client 请求按无人值守策略自动应答(cancel/decline,与 exec 行为一致)。runtime 空闲超时回收(app-server 无 shutdown 方法:stdin EOF → SIGTERM 阶梯),崩溃后下一轮自动重连并 thread/resume 盘上线程;握手失败进冷却熔断,逐轮回退 exec。

委派记账。 provider 在 spawn 时开 turn/start、settle 时关 turn/end——失败或取消(error/aborted)同样关闭——subagentTiming 的时长等于实际 CLI 运行时长;最终 assistant 消息携带从事件流解析的 token 用量。codex 的 input_tokens 含缓存命中,所以未缓存桶取 input_tokens − cached_input_tokens、cached_input_tokens 映射缓存读取、没有缓存写入概念——tokenUsage 不会双重计数缓存命中。每个续聊轮在各自递增的轮次号下重复这套记账。非 completed 终态(aborted/error)的用量回落。 被中止/失败的轮次永远收不到 turn.completed,事件流里没有用量——但 codex 已把本轮真实 token 消耗写进了 scoped home 的 rollout 文件。此时 exec 镜像改读本次 run 的 rollout 文件末条 token_count 挂用量:文件按线程 id(session_meta 头)定位,流在 thread.started 之前就被截断时按 spawn 时间窗回落;口径与 turn.completed 完全一致(input − cached 等桶,共享 usageFromCodex)。硬杀到连 token_count 都没写出的极端情况仍保持无用量,不猜测。