# 验证与依据

[后端文档](backends.md)只写结论。这些结论来自真实 CLI 探针、手动实验或上游源码，受版本限制。本文集中记录已测版本、每条结论的依据和探针用法。

## 已测版本

| 平台 | 已验证范围 | CLI 版本 |
|---|---|---|
| Windows 11 | 三家互相派发、中途消息、续接、取消；read 档 MCP、消息确认、Codex elevated sandbox、宿主通知和 Codex 插件另有补测；Codex 0.164.0 还补测了作为宿主的端到端流程和中途消息 | 基础端到端为 Claude Code 2.1.296、Codex 0.162.1、Grok 1.0.52；补测为 Claude Code 2.1.302 至 2.1.312 及其 VS Code 扩展 2.1.301、Codex 0.163.0 和 0.164.0（推送所连 daemon 为 0.160.0）、Codex 桌面端内置 0.162.0-alpha.17.2 和 0.163.0-alpha.10.2、Grok 1.0.62 和 1.0.67 |
| Linux，WSL2 Ubuntu 24.04 | 三家原生 Linux CLI 的端到端流程、sandbox 回连、进程组取消和 Codex 宿主推送 | Claude Code 2.1.296、Codex 0.162.1、Grok 1.0.52 |
| macOS | 有平台实现，真实 agent、sandbox 检测及回连尚未实测 | 未验证 |

基础验证在 2026-10-13 至 14 日，补测在 2026-10-17 至 26 日。表中记录已测组合，最低版本尚未确定。

## 依据

脚本名指 `spikes/` 下的探针。

| 结论 | 依据 |
|---|---|
| [模型查询](backends.md#模型查询)：三家原生目录查询及推理强度字段；Codex 无效强度错误附模型列表；不带 `--model` 的任务按派发默认值运行，带 `--model`、`--effort` 的任务按请求运行，`status` 和每轮结果首行显示实际模型 | `models.py`、`models.py codex --errors`、`models.py --tasks`（Claude Code 2.1.316、Codex 0.166.0、Grok 1.0.67），Windows，Claude Code 2.1.309、Codex 0.164.0、Grok 1.0.67；查询不发推理请求，错误探针使用 Codex 在 `turn/start` 拒绝的非法强度。Claude 2.1.312 的 `resolvedModel` 另由 `axiopera models claude --json` 实测。派发默认值另经手动实验，Windows，Claude Code 2.1.316、Codex 0.166.0、Grok 1.0.67：Claude `get_settings` 与一轮中 `system/init` 的模型一致，Codex `config/read` 与 `thread/start` 回复一致，Grok `currentModelId` 与 `session/new` 一致；Grok 曾在同一配置下先后报告不同默认模型；Grok 1.0.67 的 info 日志显示新会话套用 campaign 的默认模型，规则见源码 [campaigns.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/util/config/campaigns.rs#L14-L56)、[session_setup.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/agent/mvp_agent/session_setup.rs#L516-L535)，进程重新选择默认模型见 [resolution.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/agent/remote_config/resolution.rs#L135-L232)、[manager/mod.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/agent/remote_config/manager/mod.rs#L1225-L1375)。字段映射、渲染、分页、空列表、禁用项、超时回收及错误分类由单元测试覆盖 |
| [会话与消息](backends.md#会话与消息)：实际模型与推理强度的来源 | 手动实验，Windows：Claude Code 2.1.316 不经 initialize、不开启一轮即可 `get_settings`，`applied` 随 `--model`、`--effort` 变化，与一轮中 `system/init` 和 assistant 消息的模型一致；Codex 0.166.0 `thread/start` 回复的模型和强度与 `config/read` 一致；Grok 1.0.67 建立会话和每次设置配置项都发出 `model_changed`，`session/prompt` 回复的 `_meta.modelId` 与会话文件一致。Codex `model/rerouted` 依据 0.166.0 `generate-json-schema`，只影响当轮及空强度回退到目录默认值见源码 [session/mod.rs](https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/core/src/session/mod.rs#L4348-L4375)、[step_settings.rs](https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/core/src/session/step_settings.rs#L76-L87)；Claude `model_fallback` 的字段依据 2.1.316 二进制 |
| [会话与消息](backends.md#会话与消息)：Grok ACP 会话忽略 `-m`、`--reasoning-effort`，`session/set_config_option` 生效，无效值返回 `-32602` | 手动实验，Windows，Grok 1.0.67：带参数和设置配置项各跑一轮，比较 `session/prompt` 回复的 `_meta.modelId`、`model_changed` 通知和会话文件中的模型与强度；无效模型和强度各设置一次。`GROK_DEFAULT_MODEL` 同样不改变新会话的模型。切换到另一 harness 时重建 agent、丢弃 profile 见源码 [model_switch.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/agent/handlers/model_switch.rs#L60-L175)、[mvp_agent/mod.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/agent/mvp_agent/mod.rs#L935-L948)；1.0.67 目录中的模型都是 `grok-build-plan`，拒绝路径由单元测试覆盖 |
| [已测版本](#已测版本)中的端到端流程：主 agent 仅凭 `guide --host` 完成派发、收结果、追问和取消 | `host_e2e.py` |
| [宿主通知](backends.md#宿主通知)：`grok -p` 等 persistent monitor 结束才退出，`--no-wait-for-background` 让它在本轮结束时退出 | `host_e2e.py grok` |
| [权限](backends.md#权限)：read 档 MCP 工具按注解过滤 | `read_mcp.py` |
| [权限](backends.md#权限)：Grok 权限模式和工具裁剪 | `grok_perms.py`、`grok_profile.py` |
| [权限](backends.md#权限)：回连差异表中 Codex Windows 两行 | `ipc_sandbox.py`，elevated 加 `-c windows.sandbox="elevated"`；手动实验：在 elevated sandbox 中运行 `axiopera daemon status` |
| [权限](backends.md#权限)：回连差异表中 Linux 三行 | 手动实验：在三家原生 Linux sandbox 内调用 `axiopera` |
| [权限](backends.md#权限)：Codex work 档添加 ACE；MCP 服务器设为 `approve` 后免审批 | 手动实验 |
| [权限](backends.md#权限)：Codex auto_review 的审查模型，审查失败即拒绝；未配置 Windows sandbox 时 `workspace-write` 降为 `read-only` | 源码 [provider.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/model-provider/src/provider.rs#L91-L93)、[model.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/ext/guardian-reviewer/src/model.rs#L18-L76)、[completion.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/ext/guardian-reviewer/src/completion.rs#L127-L159)、[config_toml.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/config/src/config_toml.rs#L821-L839)；`auto_review_model_override` 的绕法和 `review_model` 无效见 [openai/codex#47916](https://github.com/openai/codex/issues/47916) |
| [权限](backends.md#权限)：Claude auto 分类器的模型选择和失败处理 | 文档 [permission-modes](https://code.claude.com/docs/en/permission-modes#default-classifier-model)、[errors](https://code.claude.com/docs/en/errors#auto-mode-cannot-determine-the-safety-of-an-action)；Claude Code 2.1.302 二进制中的日志字符串 |
| [权限](backends.md#权限)：Grok auto 分类器使用会话模型，失败或超时转为审批，无法解析时拒绝 | 源码 [sampler_turn.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/session/acp_session_impl/sampler_turn.rs#L830-L873)、[manager/mod.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-workspace/src/permission/manager/mod.rs#L1063-L1078)、[auto_mode/mod.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-workspace/src/permission/auto_mode/mod.rs#L1480-L1499) |
| [审批](backends.md#审批)：不使用持久化批准选项 | `codex_escalate.py`：Codex 的 amendment 会写入用户规则，`acceptForSession` 只缓存完全相同的命令 |
| [审批](backends.md#审批)：后端自行拒绝时的返回形式 | `native_block.py` |
| [审批](backends.md#审批)：Codex 撤回请求 | 手动实验，Windows、Codex 0.167.0，2026-11-07：read-only 加 on-request 的线程中，命令审批应答 decline 之后收到 `serverRequest/resolved`，`requestId` 与请求的 JSON-RPC ID 相同。网络请求在裁决前结束时撤回依据源码 0.167.0 [bespoke_event_handling.rs](https://github.com/openai/codex/blob/rust-v0.167.0/codex-rs/app-server/src/bespoke_event_handling.rs#L836-L846)、[outgoing_message.rs](https://github.com/openai/codex/blob/rust-v0.167.0/codex-rs/app-server/src/outgoing_message.rs#L232-L241)，未实测触发。适配器按 ID 撤回、daemon 作废并记录 `withdrawn` 由单元测试覆盖 |
| [会话与消息](backends.md#会话与消息)：Claude read 档需另加 `--permission-prompt-tool stdio` | `read_mcp.py` |
| [会话与消息](backends.md#会话与消息)：中途消息和消费确认 | `steer.py`、`message_receipts.py`；源码 [Codex tasks/mod.rs](https://github.com/openai/codex/blob/ce0323f2f2d3b25e82806cd555237da3db4e1897/codex-rs/core/src/tasks/mod.rs)、[Grok interjection.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/session/acp_session_impl/interjection.rs) |
| [任务与工作目录](usage.md#任务与工作目录)：`send --tier` 保留会话并切换权限 | `tier_resume.py`，Windows，2026-10-29，Claude Code 2.1.312、Codex 0.165.0、Grok 1.0.67：`read → full → read` 三轮会话 ID 一致，full 轮将首轮记住的标记写入文件，切回 read 后文件保持不变。档位持久化、父子权限约束、运行中切换的拒绝和同档位中途消息由单元测试覆盖 |
| [会话与消息](backends.md#会话与消息)：Grok 空闲时的消息，以及一次 prompt 内的多段答复 | `grok_idle_interject.py`、`grok_response_boundary.py` |
| [会话与消息](backends.md#会话与消息)：Grok 工具名、参数摘要及后续更新 | 上游 [tool_calls.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-shell/src/session/acp_session_impl/tool_calls.rs)、[use_tool/input.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-tools/src/implementations/use_tool/input.rs)；适配器、daemon 和 `top` 的单元测试覆盖参数提取、MCP 展开、更新去重与调用计数；未新增真实 agent 探针 |
| [会话与消息](backends.md#会话与消息)：后台命令结束后自行开启一轮 | `background.py` |
| [结果与接管](usage.md#结果与接管)：审批请求先于更早的结果交出，交出前不能批准；过长的提问和留言只给首尾，全文写入文件；agent 自行开启的一轮从开始就计入进度 | `delivery.py` |
| [会话与消息](backends.md#会话与消息)：并发续接 | `resume.py` |
| [会话与消息](backends.md#会话与消息)：Grok 原生子 agent 在直接及 Axiopera 混合嵌套中的收件隔离 | `grok_native_identity.py`，Windows、Grok 1.0.67，2026-10-26：直接启动使用 auto，经 Axiopera 启动使用 work，再各派一个原生子 agent；原生子 agent 实际派发只读 Axiopera 任务，主代理先 `inbox` 未取走结果，子 agent 随后成功收取；另用采集的身份与预置结果检查原任务及子会话的归属 |
| [会话与消息](backends.md#会话与消息)：Codex 原生子 agent 在直接及 Axiopera 混合嵌套中的收件隔离 | `codex_native_identity.py`，Windows、Codex 0.164.0，2026-10-26：直接启动使用 `danger-full-access`，经 Axiopera 启动使用 full，再各派一个原生子 agent；原生子 agent 实际派发只读 Axiopera 任务，主代理先 `inbox` 未取走结果，子 agent 随后成功收取；另用采集的身份与预置结果检查原任务及子线程的归属 |
| [宿主通知](backends.md#宿主通知)：Claude 和 Grok 在本轮进行中能否收到后台命令的完成通知 | `background.py busy` |
| [宿主通知](backends.md#宿主通知)：Codex 后台状态显示 | `status_watch_*` 单元测试覆盖排队、工具进展、轮末后台工作、调用方隔离、交付并行和自动退出；guide 与 CLI 参数由单元测试覆盖。Windows、Codex 0.166.0，2026-11-03：`thread/backgroundTerminals/list` 已有 `watch --status`，用户反馈 `/ps` 未显示。源码 [启动事件去重](https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/app-server/src/bespoke_event_handling.rs#L1075)与[界面登记](https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/chatwidget/command_lifecycle.rs#L35)符合审批先发无 process ID 事件的缺陷路径，归因尚缺该次事件流。后台命令结束不唤醒见 [async_watcher.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/core/src/unified_exec/async_watcher.rs#L155-L243)。桌面端和 VS Code 扩展的显示效果未实测 |
| [宿主通知](backends.md#宿主通知)：Claude 内置子 agent 和 agent team teammate 空闲时能否被唤醒 | 手动实验，Windows、Claude Code 2.1.312，2026-10-29：内置子 agent 和 in-process teammate 各后台运行 30 秒命令后结束本轮，用标记文件判断唤醒；子 agent 被唤醒，teammate 直到收到消息并再调用一次工具才收到通知；teammate 的 Monitor 事件同样不唤醒它。端到端：子 agent 后台运行 `axiopera wait` 后被唤醒并取到结果；teammate 前台运行 `wait`，自行调长 Bash 超时，等待 2 分 45 秒后取到结果。只给 guide 的取结果说明时，按现写法 3 个普通子 agent 后台运行 `wait`、2 个 teammate 前台运行，全部带任务 ID；不点明 `team-lead` 时普通子 agent 会自认 teammate，任务 ID 一句不说明共享收件箱或不以子 agent 为主语时常被跳过。已知问题见 [claude-code#91503](https://github.com/anthropics/claude-code/issues/91503) |
| [宿主通知](backends.md#宿主通知)：Codex 推送通道，以及 TUI 退出后会话的卸载时间 | `codex_host_push.py`；手动实验：TUI 退出后轮询 `thread/loaded/list`，daemon 0.160.0 和 `--remote` 连接的 0.164.0 app-server 各一次；源码 0.162.0 [config_toml.rs](https://github.com/openai/codex/blob/c1382380de69521303b416720a52f42d51af6248/codex-rs/config/src/config_toml.rs#L346-L348)、0.164.0 [config_toml.rs](https://github.com/openai/codex/blob/6aaac694803004a63c6f393d153c96d22521a6b9/codex-rs/config/src/config_toml.rs#L349-L352) |
| [宿主通知](backends.md#宿主通知)：Codex 用户消息的 `clientUserMessageId` 按 `clientId` 读回 | `codex_client_message_id.py`，Windows，2026-11-10 至 11 日，Codex 0.167.0 的私有 app-server：`turn/start` 和 `turn/steer` 的消息都按 `clientId` 读回，含制表符、行尾空格、CRLF 和末尾空行的正文逐字一致；`turn/steer` 的消息在被接受后立即读回时不在列表中，本轮结束后在；`thread/queue/add` 排入空闲会话的消息在它开启的一轮结束后按 `clientId` 读回；另起进程读未加载的会话，以及 `thread/resume` 之后，结果相同。旧版本未运行，只查源码：0.160.0 [turn_processor.rs](https://github.com/openai/codex/blob/a956835d020762cb2b570053af06f643a11c0ecc/codex-rs/app-server/src/request_processors/turn_processor.rs#L618)、[thread_history.rs](https://github.com/openai/codex/blob/a956835d020762cb2b570053af06f643a11c0ecc/codex-rs/app-server-protocol/src/protocol/thread_history.rs#L517)；该字段及其处理自 0.136.0 的源码起存在，0.135.0 没有 |
| [宿主通知](backends.md#宿主通知)：只开关 feature 的 `-c` 不让 TUI 离开共享 daemon | 源码 Codex 0.164.0 [daemon_startup.rs](https://github.com/openai/codex/blob/6aaac694803004a63c6f393d153c96d22521a6b9/codex-rs/tui/src/daemon_startup.rs#L90-L126) |
| [宿主通知](backends.md#宿主通知)：Codex 门铃，包括宿主自行 `inbox` 后撤回提醒；app-server 客户端会话的来源为 `vscode` | `codex_doorbell.py` |
| [宿主通知](backends.md#宿主通知)：Codex 插件 hook 在工具调用之后提醒，隐藏的工具仍可由 hook 调用；不调工具时由本轮之后的门铃提醒 | `codex_hooks.py`：hook 和 MCP 服务器经线程配置提供；原提示额外要求服从工具调用之间到达的指令，删去该句后的自主收件行为尚未复测；手动实验：在桌面端安装并信任插件后新建会话复测，缓存中插件的 `mcp.json` 临时直接设了 `AXIOPERA_HOME` |
| [宿主通知](backends.md#宿主通知)：Grok monitor 在工具调用之后和空闲时送达 `watch` 的输出，以及它的速率和行长限制；monitor 启动的命令没有 `GROK_SESSION_ID` | `grok_monitor.py`：原提示额外要求服从调用间指令，删去该句后的自主收件行为尚未复测；手动实验：同一命令经 monitor 和终端工具各运行一次；源码 [Grok monitor rate_limiter.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-tools/src/implementations/grok_build/monitor/rate_limiter.rs)、[event.rs](https://github.com/xai-org/grok-build/blob/2bdd1d6a6369de0e8c68132ea4539e9abd9e14a8/crates/codegen/xai-grok-tools/src/implementations/grok_build/monitor/event.rs) |
| [Skill 与 Codex 插件](usage.md#skill-与-codex-插件)：skill 的读取位置 | Grok 在隔离的主目录中用 `grok inspect` 实测；文档 [Claude skills](https://code.claude.com/docs/en/skills)；源码 [Codex host_roots.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/ext/skills/src/host_roots.rs) |
| [Skill 与 Codex 插件](usage.md#skill-与-codex-插件)：Codex 插件的安装、卸载和卸载后的残留，包括 hook 的信任记录和内容基线 | 手动实验：在临时 `CODEX_HOME` 中和桌面端分别安装、信任和卸载，再运行 `axiopera plugin cleanup`；源码 Codex 0.164.0 [plugin_trust.rs](https://github.com/openai/codex/blob/6aaac694803004a63c6f393d153c96d22521a6b9/codex-rs/hooks/src/engine/plugin_trust.rs#L51-L117) |
| [Skill 与 Codex 插件](usage.md#skill-与-codex-插件)：卸载不结束已打开会话中的 hook 进程 | 手动实验：桌面端 |
| [宿主通知](backends.md#宿主通知)：VS Code 的 hook 支持与插件加载 | 维护者确认 [openai/codex#17930](https://github.com/openai/codex/issues/17930)；Codex 0.164.0 [插件加载](https://github.com/openai/codex/blob/6aaac694803004a63c6f393d153c96d22521a6b9/codex-rs/core-plugins/src/manager.rs#L698-L702)、[hook 加载](https://github.com/openai/codex/blob/6aaac694803004a63c6f393d153c96d22521a6b9/codex-rs/core-plugins/src/manager.rs#L1004-L1023) |
| [Skill 与 Codex 插件](usage.md#skill-与-codex-插件)：TUI 启动时的 hook 确认，以及需要重新信任的条件 | 源码 Codex 0.163.0 [startup_hooks_review.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/tui/src/startup_hooks_review.rs)、[discovery.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/hooks/src/engine/discovery.rs#L666)；0.164.0 [plugin_trust.rs](https://github.com/openai/codex/blob/6aaac694803004a63c6f393d153c96d22521a6b9/codex-rs/hooks/src/engine/plugin_trust.rs)、[plugin_fingerprint.rs](https://github.com/openai/codex/blob/6aaac694803004a63c6f393d153c96d22521a6b9/codex-rs/hooks/src/engine/plugin_fingerprint.rs) |
| [Skill 与 Codex 插件](usage.md#skill-与-codex-插件)：hook 的开销 | 手动实验：直接调用 debug 构建的 `axiopera mcp --codex-hooks`，daemon 未运行和运行时各 20 次 |
| [宿主通知](backends.md#宿主通知)：队列的检查间隔和分发规则 | 源码 [Codex queue service.rs](https://github.com/openai/codex/blob/83086188ae0614bd882818ff1aa23f3194962012/codex-rs/ext/queue/src/service.rs#L89-L245) |
| [宿主通知](backends.md#宿主通知)：Claude Code VS Code 扩展的后台 `wait` 唤醒；Codex 桌面端和 VS Code 扩展的私有 app-server；桌面端处理外部排入的队列消息 | 手动实验 |
| [宿主通知](backends.md#宿主通知)：不向 Claude inbox socket 推送 | 手动实验；文档 [Claude 跨会话消息](https://code.claude.com/docs/en/cross-session-messaging) |
| [宿主通知](backends.md#宿主通知)：Windows 上 Codex 的退出码 | 手动实验；源码 [Codex shell.rs](https://github.com/openai/codex/blob/ce0323f2f2d3b25e82806cd555237da3db4e1897/codex-rs/core/src/shell.rs#L34-L40) |
| [daemon 生命周期](design.md#daemon-生命周期)：Windows 进程存活、Job 取消和命名管道权限 | `daemon_job.py`、`ipc_sandbox.py`、`winproc/` |
| [身份与 IPC](design.md#身份与-ipc)：Codex Windows sandbox 中的进程不能为 daemon 的管道另建实例，抢先创建的管道被客户端拒绝；sandbox 中的新旧客户端仍能连接 | `pipe_squat.py`，Windows、Codex 0.166.0，2026-11-04；未收紧 DACL 时，8 次连接中有 3 次落到 sandbox 另建的实例，且服务端进程核对没有发现 |
| [身份与 IPC](design.md#身份与-ipc)：Linux 客户端在 sandbox 中启动 daemon 的条件 | 手动实验，WSL2、Grok 1.0.52、2026-11-04：`--sandbox workspace` 中数据目录在工作区外时启动失败，在工作区内时 daemon 在 sandbox 中启动、Grok 退出后仍在运行，且同一 sandbox 的 `gc` 被接受；Codex 0.162.1 `codex sandbox -P :read-only`、`:workspace` 不论 daemon 是否运行，`connect` 都收到 EPERM。Claude Code 2.1.296（装有 socat）默认 sandbox 中不论 daemon 是否运行都收到 EPERM；`sandbox.network.allowAllUnixSockets` 为 true 且数据目录在工作区内时，daemon 在 sandbox 中启动并接受同一 sandbox 的 `gc`，该条命令结束时随 PID 命名空间终止。macOS 依据用户反馈：Claude Code 命令 sandbox 中的首次调用启动了 daemon |
| [指定调用方](usage.md#指定调用方)、跨机器的[宿主通知](backends.md#宿主通知)：会话变量传不过边界时用 `--caller` 分开收件，Claude 的后台 `wait` 和 Grok monitor 照常送达；子 agent 的 `--caller` 离不开所在任务 | 用户反馈，Ubuntu 24.04、Axiopera 0.3.2、本机 Claude Code 经 ssh 调用：spawn、send、后台 `wait` 唤醒和 `inbox` 正常，ssh 断开后 daemon 与任务继续运行，调用方因会话变量没有传过去成为 `user`。手动实验，2026-11-10：Windows 上的 Claude Code 2.1.322 经 `wsl.exe` 调用 WSL2 Ubuntu 中的 Axiopera，会话变量没有进入 WSL；带 `--caller` 派发的 Claude Code 2.1.296 read 档任务只对该会话可见，`user` 和另一会话的 `status` 都为空，`user` 的 `inbox` 也没有消息；后台 `wait` 退出后唤醒宿主，`inbox` 取到结果；不带 `--caller` 的 `guide --host claude` 给出指明调用方的提示。该子 agent 运行 `--caller user` 和 `--caller task:<其他任务>` 被客户端拒绝，以 `--caller claude:<任意>` 派发 full 档任务被 daemon 按档位拒绝。Grok 1.0.67 作宿主（ACP、yolo）时，提示只说明 Axiopera 在另一台机器上、经 `wsl.exe -d Ubuntu -e <axiopera>` 调用，未提 `--caller`：Grok 读 guide 后从 `GROK_SESSION_ID` 取会话 ID，此后每条命令都带 `--caller grok:<会话>`；monitor 经 `wsl.exe` 运行的 `watch` 在它忙时、下一次工具调用之后送达子任务完成的消息，随后 `inbox` 取到结果。组合规则和格式检查另由单元测试覆盖 |

提示词审查后的协议核对：`question_receipts_match_the_task_answer_route` 验证主会话与原生子会话的回执、实际回答队列和查询；`grok_spawn_receipts_use_the_callers_monitor` 验证 Grok 宿主、任务及混合原生会话的收件指引。拒绝原因按只读限制、审批通道断开和后端缺少批准选项分别表述。探针提示已删冗余和额外行为引导，历史实测对应原提示；新版仅作语法与本地断言核对，尚未重新调用真实模型。

## 探针

探针调用真实 CLI，会消耗 token，只在需要验证真实行为时手动运行。各脚本顶部说明参数。

需要 Python 3.12 或更高版本，并安装、登录待测 CLI。探针从 PATH 定位程序；Windows 的 Claude/Codex npm 入口会解析为原生 exe。自定义安装可以通过 `AXIOPERA_PROBE_CLAUDE`、`AXIOPERA_PROBE_CODEX`、`AXIOPERA_PROBE_GROK` 指定可执行文件路径。

调用 Axiopera 的探针使用 `target/debug/axiopera`，Windows 使用对应 `.exe`，先运行 `cargo build --locked`。交互终端探针在 Windows 上需要 `python -m pip install pywinpty`。`daemon_job.py`、`ipc_sandbox.py` 和 `pipe_squat.py` 仅用于 Windows，先构建辅助程序：

```sh
cargo build --release --locked --manifest-path spikes/winproc/Cargo.toml
```

例如：

```sh
python spikes/host_e2e.py claude
python spikes/message_receipts.py codex
python spikes/read_mcp.py grok
```

手动验证 daemon 时，用临时 `AXIOPERA_HOME` 隔离数据目录。测试结束后停止该 daemon，删除测试目录和测试创建的原生会话。`probe.forget_sessions` 清理指定测试工作目录下的 Claude、Grok 会话；Codex 会话需按探针取得的 thread ID 清理，`resume.py` 有 `thread/delete` 示例。

协议排查可在启动测试 daemon 前设置 `AXIOPERA_TRACE_PROTOCOL=1`。原始收发内容写入 `tasks/<id>/protocol.log`，可能包含任务内容和工具参数。测试结束后连同测试数据目录删除。