GPT-5.6-sol: optional tool parameters are exposed as required (file writes fail)

[slicenferqin]

Summary

GPT-5.6-sol via openai-codex-responses treats optional tool parameters as required, so every write/bash call must submit sandbox_permissions and justification, which then fail validation. See root cause below.

Dependency-level tracker

earendil-works/pi#8105

[slicenferqin]

Dependency-level tracker created upstream: earendil-works/pi#8105

[slicenferqin]

Verified on GPT-5.6-sol after switching the session's tool presentation from native function calling to PTC / Code Mode: file creation and writing now succeed.

Isolation evidence: the filesystem backend, sandbox policy, canonical tool runtime, and the write executor are all functional. The failure is confined to the native function-tool schema/calling path, where optional parameters (sandbox_permissions, justification, etc.) are emitted as if required.

Why the workaround works: in Code Mode the model sees only the outer run_code tool, whose two parameters (code, description) are genuinely required; nested write/bash calls are dispatched internally against the canonical schemas.

Workaround: use PTC / Code Mode for GPT-5.6-sol until native optional-parameter handling is fixed.

This is a workaround and diagnostic signal, not the root fix, and sandbox escalation validation (validateEscalationArgs) should not be relaxed.

Dependency-level tracker: earendil-works/pi#8105

[kirkchinese]

补充一组绕过 DSH 的直接边界探针，以及对当前根因描述的修正。

结论摘要

当前 Discussion 和关联的 earendil-works/pi#8105 将现象描述为 optional 参数在 Codex 工具路径中“表现为 required”。这个用户侧描述是准确的，但进一步隔离后发现：

1. DSH 的 canonical tool schema 确实只把真正必填的字段放入 required；
2. DSH 的 pi-ai / Anthropic Messages 路径保留了该 required 数组；
3. CC Switch 3.19.2 的 Anthropic → Responses 转换也没有扩充 required；
4. 但 GPT/Codex 会为 Schema 中声明、却不在 required 中的属性主动生成类型合法的默认值。

因此，更准确的直接触发因素不是“DSH 把 optional 标成 required”，而是：

Codex 工具调用会 materialize 所有已声明的顶层属性；DSH 又把 escalation 字段的“存在”解释为真实升级请求。

直接探针

我绕过 DSH，直接向本机 CC Switch 的 Anthropic Messages 入口发送了以下工具 Schema：

{
  "type": "object",
  "properties": {
    "required_value": { "type": "string" },
    "optional_text": { "type": "string" },
    "optional_mode": {
      "type": "string",
      "enum": ["alpha", "beta"]
    }
  },
  "required": ["required_value"]
}

Prompt 明确要求：

Call the probe tool once with required_value set to ok.
Do not invent optional values.

链路为：

Anthropic Messages
  → CC Switch 3.19.2
  → apiFormat=openai_responses
  → Codex OAuth
  → https://chatgpt.com/backend-api/codex/responses
  → gpt-5.6-sol

最终返回：

{
  "required_value": "ok",
  "optional_text": "",
  "optional_mode": "alpha"
}

即 optional string 被填成 ""，optional enum 被填成第一个 enum 值。这与 DSH 中观察到的行为完全对应：

{
  "sandbox_permissions": "workspace-write",
  "justification": ""
}

Nullable 对照实验

将两个 optional 字段改成：

{
  "optional_text": {
    "oneOf": [{ "type": "string" }, { "type": "null" }]
  },
  "optional_mode": {
    "oneOf": [
      { "type": "string", "enum": ["alpha", "beta"] },
      { "type": "null" }
    ]
  }
}

同一路由返回：

{
  "required_value": "ok",
  "optional_text": null,
  "optional_mode": null
}

这证明 nullable 能让当前 Codex 路径表达“未提供”，但 DSH 当前的 escalation 参数只接受 string，因此仍需要一侧做归一化。

与 pi#8105 的关系

pi#8105 将问题定位到 openai-codex-responses 的 strict: null。本次复现使用的是：

DSH pi-ai anthropic-messages
  → CC Switch Anthropic endpoint
  → CC Switch 自己转换为 Codex Responses

因此没有经过 pi-ai 的 openai-codex-responses 请求适配器，但仍复现相同的 optional materialization。这表明 strict: null 可能是某条路径上的触发或放大因素，但不是此行为唯一成立的必要条件。更广义的问题是 Codex Responses 工具调用与 Anthropic optional-property 语义之间的兼容。

CC Switch 侧的兼容性报告：

farion1231/cc-switch#6473

对 DSH 的建议

CC Switch 作为协议桥，可以通过 optional → nullable、返回时 null → omission 来保持 Anthropic 语义。同时，DSH 仍可以做独立 hardening，避免控制型 optional 字段被模型自动补值后阻塞普通调用。

最小兼容修复

对 sandbox_permissions 和 justification 允许显式 null，并在进入 escalation 校验前将 null 归一化为“未提供”。涉及：

packages/shell/tool-bash
packages/shell/tool-pwsh
packages/fs/tool-fs
packages/fs/tool-fs/src/sandbox

非扩权 no-op

在解析 standing policy 后，如果模型提供的已知目标等于或窄于当前有效模式，可以考虑将这对字段视为冗余 metadata：

danger-full-access + requested workspace-write
danger-full-access + requested danger-full-access
workspace-write + requested workspace-write

这些情况不授予任何新能力，也不应触发 approval。真正变宽的请求仍必须保持现有流程：

read-only → workspace-write
read-only → danger-full-access
workspace-write → danger-full-access

不得削弱 strictly-wider 校验、非空 justification、approval 或 never 下的 fail-closed 行为。这一方向也与 #1292、#468 和 #1201 的建议一致。

更稳健的长期方案

不要仅凭模型提供了 sandbox_permissions 就认定它是一次合法升级重试。可以考虑：

1. 普通调用先发生真实 sandbox denial；
2. denial 返回一次性 escalation_token；
3. 只有携带该 token 的精确重试才能请求更宽模式；
4. 没有有效 token 的冗余 escalation 参数不进入审批路径；
5. 或把普通工具与 escalation retry 拆成两个独立工具。

建议回归测试

为 bash、pwsh、write 和 edit 增加共同测试：

1. danger-full-access + approval never + escalation fields = null：普通操作成功，不触发 approval。
2. danger-full-access + workspace-write + empty justification：若采纳 no-op 方案，按当前 standing policy 执行，不触发 approval。
3. workspace-write + danger-full-access + valid justification：仍要求 approval。
4. workspace-write + danger-full-access + approval never：仍 fail closed。
5. 未知 mode、字段只出现一半，以及真正 widening 时空 justification：仍严格拒绝。
6. 能正常省略 optional 字段的 provider：行为保持不变。

在 gpt-5.6-sol + ChatGPT Codex OAuth Responses 这条具体路由上，Codex 会对 schema 中声明但不在 required 里的顶层 optional 属性生成类型合法的非空默认值（观察为 string→""、enum→首个枚举值）。DSH 把 sandbox_permissions + justification 的成对存在解释为升级请求，因此普通调用被卡住。strict:null 不是该路由的必要条件；pi-ai 原生 codex 路径上的 strict:null 仍可能另有独立影响。

[slicenferqin]

感谢补充这组直接边界探针和 nullable 对照实验——这比仅仅观察 DSH 内部现象更有说服力。

我们同意修正措辞：DSH 的 canonical tool schema 确实只把真正必填的字段放进 required，问题不是“DSH 把 optional 标成了 required”，而是 Codex 会对已声明但不在 required 里的顶层 optional 属性主动 materialize 类型合法的默认值（observed：string→""、enum→首个枚举值），而 DSH 又把 escalation 字段的“存在”解释为真实升级请求。

你的复现链路（DSH pi-ai anthropic-messages → CC Switch 3.19.2 → Codex Responses）没有经过 pi-ai 的 openai-codex-responses 适配器，因此也证明 strict: null 不是该行为成立的必要条件；但它在 pi-ai 原生 codex 路径上是否另有独立影响，仍需一组直接 A/B 才能定论。

接下来我们会：

1. 更正 earendil-works/pi#8105 的标题与因果措辞（不再把 strict: null 当作唯一根因）；
2. 保留 PTC/Code Mode 仅作为临时 workaround，不作为根修复；
3. 在 DSH 侧评估独立的 escalation hardening——优先试验 escalation 字段接受 nullable（string | null），并在进入 escalation 校验前把 null 归一化为“未提供”，同时完整保留成对校验、strictly-wider、approval 与 fail-closed 语义。

在归因到 strict 之前，仍需在 pi-ai 原生 codex 路径上做直接 A/B（strict: null / false / 省略，以及 nullable schema）。感谢澄清。

[KaspaPulse]

I agree with the denial-bound direction described above. I think the key invariant should be:

model output is a request, not authorization.

A model-supplied sandbox_permissions value should never be sufficient by itself to enter an approval/escalation path.

For a robust model-agnostic design, I would bind escalation eligibility to a real prior denial for the exact operation, with the eligibility scoped to the session, tool, normalized command/operation, workdir or target path, and effective sandbox mode.

Ideally that eligibility should also be short-lived and single-use, so parallel or unrelated tool calls cannot inherit it.

One compatibility detail I would favor: if escalation fields arrive without valid denial evidence, treat them as non-authoritative metadata and execute the call at the standing privilege instead of failing it. If wider access is genuinely required, the normal execution will produce the denial that makes a retry eligible.

Suggested regression coverage:

speculative escalation fields do not elevate or fail a permitted call
exact denied retry can request escalation
changed command/path/workdir cannot reuse eligibility
eligibility is single-use and expires
parallel denials cannot cross-authorize
rejected approval never executes with wider privilege
behavior is identical across bash, pwsh, write, and edit

This would fix the current GPT-5.6 behavior without introducing any model-specific logic and would strengthen the sandbox contract for future models as well.

[weijiafu14]

Adding a cross-path datapoint to the isolation work above (which we agree with — the refined framing that the Codex side materializes declared-but-optional top-level properties matches what we see from the schema side).

We ran the same model — GPT-5.6-sol on a ChatGPT-subscription OAuth login — through a different path: pi2dsh's built-in OpenAI-Codex route on a stock @deepseek-ai/dsh@0.1.1-rc.2, driving a real write on a clean workspace, with the submitted arguments read back from the session log:

• the model's write call carried exactly ["file_path", "content"] — neither sandbox_permissions nor justification was materialized;
• validation accepted the call, the file landed on disk with the requested content, and the turn closed completed.

So on this path the failure mode of this thread does not reproduce: nothing forced the optional parameters into the call, and nothing rejected the call for omitting them. Evidence (arg keys, call id, verdict): codex-write-optional-e2e.json, harness verify-codex-write-optional-e2e.mjs.

Scope notes, honestly: this is a single-run datapoint from a different transport configuration, so it does not refute the root-cause analysis for the openai-codex-responses path this thread isolated — it narrows it: the same model + same account + same tool family can complete writes without optional-parameter materialization, which is consistent with the conclusion that the behavior lives in how that specific wire presents the schema, not in the model being unable to omit optionals. Also, the run used our current working tree (the credential wiring involved is newer than the published 0.23.0), so treat it as a reference measurement rather than something to install today.