看清前后端的
当前版本的通讯。
按已核查的桌面 App 版本与初始化规则筛选 method。本页是静态参考，并非运行时接口探测结果。展开请求，左右对照参数和响应；继续展开字段，查看联合类型、嵌套对象、必填项与原始说明。
两个方向都可以发起请求。响应通过同一个 id 配对，本身没有 method。
请求：{id, method, params} → 响应：{id, result} 或 {id, error}。通知：{method, params}，没有 id，也不等待 RPC 响应。
例如 turn/start 的返回值是 TurnStartResponse；turn/started 是另一条通知。这里展示 Codex 实际信封格式，省略其线上不携带的 jsonrpc 字段。
先看整体链路：一次权限审批是怎样往返的？
item/permissions/requestApproval · id=42 → 前端展示审批并回复
id=42 · result → Core 处理授权并返回工具结果
这条是服务端主动发起的请求，前端是响应方。当前会话没有暴露 request_permissions 工具；这里仅解释该已注册 method 的通讯形态，不表示当前工具会触发它。
跳转到完整权限请求与响应 ↓核查版本：0.155.0-alpha.9.2；桌面前端初始化启用 experimentalApi。
基于正在运行的 App 所用二进制重新导出协议；根据当前桌面前端初始化代码的 optOutNotificationMethods，移除 15 个已取消订阅的通知，包括 turn/diff/updated、thread/compacted 和两个 rawResponse 通知。实验性请求仍保留。
判定边界：已核查运行二进制、启动参数及已安装前端初始化规则，未抓取现有 stdio 连接握手帧。本页表示有证据支持的协议可用范围；登录、平台、权限、任务状态及功能前置条件仍在调用时检查，不能保证每个请求都会成功。
工具是否暴露和 RPC 是否注册是两层配置。因此 request_permissions 未暴露时，item/permissions/requestApproval 也不应仅凭工具清单被删除。当前启动覆盖为 features.code_mode_host=true，用户配置中 js_repl=false；它们不是 method 总开关。
JSON 示例包含所选对象分支的全部字段，ID 与内容为占位值；其他分支可展开 Schema。3 个旧版接口提供对应二进制导出的完整 TypeScript 定义。原始完整目录已保存在本地备份中。
公共错误响应与 ID 关联
请求处理失败时，返回与请求相同的 id 和 error 对象，不能同时返回 result。下面是结构示例，并非所有方法都会触发同一种错误。
{
"id": 42,
"error": {
"code": -32600,
"message": "Invalid request"
}
}threadId / turnId / itemId 是业务对象标识，用于定位任务、轮次与条目；RPC id 只负责一次请求与响应的配对。通知中的这些业务 ID 不会把通知变成 RPC 响应。