App Server: expose signed per-thread effective capability and zero-history receipts

What variant of Codex are you using?

Codex Desktop/App Server on macOS

• ChatGPT app: 26.727.51351 (build 6119)
• Bundled runtime: codex-cli 0.146.0-alpha.9.2

What feature would you like to see?

A trusted App Server/supervisor API that can launch a fresh top-level thread and return an authoritative, signable receipt for the exact effective worker boundary.

This is needed by hosts that must prove a proposal-only worker has no inherited history and no shell, Node, writable filesystem, inherited environment, nested-agent, Gmail, browser, signed-in app, or message-sending capability before delivering the worker brief. A profile file, request parameters, model output, or caller assertion cannot safely provide that proof.

Current gap

thread/start currently returns useful fragments such as the thread identity, sandbox, approval policy, instruction sources, and active permission-profile provenance. However, it does not return:

• a complete effective capability/tool manifest after config, permission, plugin, app, MCP, and built-in tool resolution;
• the exact selected worker/profile content hash;
• an authoritative zero-history receipt with parent/fork and initial history/input counts;
• runtime-owned rejection receipts for forbidden capabilities; or
• a signed/attestable envelope bound to the runtime and exact thread.

Separate calls such as config/read, permissionProfile/list, plugin/installed, app/list, and mcpServerStatus/list are useful for diagnostics, but they are not an atomic thread-specific proof and cannot establish the absence of built-in or dynamically resolved capabilities.

The generated App Server schema also has no effectiveCapabilityManifest field on ThreadStartResponse.

Requested control-plane evidence

Please expose either one atomic launch receipt or a small set of host-owned methods that provide:

1. Runtime build and protocol/schema hash.
2. Exact new thread/task ID.
3. Zero-history proof: no parent, no fork, no resume, zero initial turns/input/history items.
4. Exact profile/instruction source IDs, paths, and SHA-256 hashes.
5. Effective sandbox, approval policy, writable roots, environment-inheritance policy, and selected capability roots.
6. Resolved permission-profile ID plus a hash of the complete effective permission state.
7. Complete built-in tool, dynamic tool, skill, plugin, app, connector, and MCP manifest, including authentication and read/write capability classification.
8. Side-effect-free runtime rejection receipts for forbidden capability probes.
9. Issued time, expiry, signer identity, payload hash, and host signature.
10. An authoritative worker-termination receipt.

The receipt must be produced by the trusted host/runtime, not by the worker, model, caller, environment variables, or static profile text. Any runtime, profile, plugin, permission, or manifest drift should invalidate it.

Possible API shape

• Enrich thread/start with zeroHistoryProof and effectiveCapabilityManifest;
• add a side-effect-free thread/capability/probe method returning runtime-owned rejection receipts; and
• add an authoritative termination receipt or host-signed combined boundary receipt.

This is adjacent to #30967, which requests first-class per-thread skill/plugin selection. This request is specifically about authoritative evidence of the final resolved boundary so another service can enforce fail-closed readiness before a worker receives sensitive or action-adjacent work.

Safety outcome

Without this interface, downstream systems must remain blocked rather than infer isolation from config files or worker self-report. With it, they can verify one real host-supervised worker and safely gate higher-consequence workflows.