Expose privacy-preserving attestation for encrypted collaboration.spawn_agent arguments

Variant

Codex App / app-server / CLI collaboration tools on macOS arm64.

Observed with:

• Codex App 26.727.51351 (6119)
• bundled CLI 0.146.0-alpha.9.2
• openai/codex main ee0247f95a6fe2b094ba2253d82cae2a2b4c2dff
• model-reserved collaboration.spawn_agent

Feature request

Please expose an opt-in, privacy-preserving, independently verifiable pre-dispatch attestation for encrypted collaboration tool arguments, especially collaboration.spawn_agent.

The attestation should let a caller prove that the native invocation delivered to the collaboration backend matched an expected projection without changing the reserved tool schema or persisting plaintext.

A sufficient receipt would bind at least:

• receipt schema and canonicalization version
• function namespace/name and tool-schema identity
• call ID, parent thread ID, child thread ID, and canonical agent path/task name
• requested and effective agent type
• requested and effective fork_turns
• requested task name
• SHA-256 and byte length of the decrypted message
• SHA-256 of the canonical full argument projection
• dispatch outcome and generation timestamp

The receipt must originate at the authoritative boundary that can observe the decrypted arguments immediately before child creation. It should be platform-signed or otherwise independently verifiable. Plaintext should be omitted by default.

An optional strict mode should fail before creating the child when the receipt cannot be produced.

Motivation

High-assurance review and compliance workflows sometimes need to prove that an independently spawned reviewer received one exact prompt, role, task name, and no inherited conversation history. Model prose, caller-owned intent capsules, returned task names, or post-hoc child reports cannot prove the actual native invocation.

Codex correctly marks spawn_agent.message as encrypted. The local handler receives encrypted_function_args metadata and routes the message through the encrypted inter-agent path. That preserves privacy, but it means a trusted local extension cannot compare the actual invocation with a caller-known plaintext digest.

Changing the reserved schema to make message plaintext is not viable: the Responses backend rejects a non-canonical collaboration.spawn_agent schema. A first-class attestation boundary would preserve encryption and the canonical schema while enabling auditability.

Minimal reproduction of the capability gap

1. Use the Codex App with the model-reserved collaboration.spawn_agent tool.
2. Keep the canonical schema unchanged, including encrypted message.
3. Add local instrumentation at the start of the native MultiAgentV2 spawn handler, before child creation.
4. Invoke an ordinary non-sensitive child with explicit agent_type, task_name, fork_turns: "none", and a known message.
5. Observe that the client can classify message as an encrypted function argument and forward it through the encrypted inter-agent path, but cannot independently bind the native call to the caller-known plaintext message digest.
6. If the instrumentation requires locally visible plaintext, it must fail before child creation; no attestation receipt can be emitted.

Expected behavior

Codex should provide one supported way to obtain an independently verifiable digest/receipt for the decrypted native invocation while preserving encrypted transport and the exact reserved collaboration schema.

This is not a request to disable encryption, expose prompt plaintext in logs, or let clients redefine reserved tool schemas.

Related issues

• #20204 tracks missing PreToolUse coverage for MultiAgent handlers, but a generic local hook still needs an authoritative digest for encrypted fields.
• #31864 shows why the reserved collaboration schema must remain exact.
• #26753 and #33267 document adjacent encrypted collaboration-tool behavior.