Expose a privacy-minimal output-only human-input lifecycle from codex-core #39426

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Aug 19, 2026
2. owieschon commented on Sep 6, 2026

   

   owieschon

   on Sep 6, 2026

   More actions

   Reproduced a downstream consequence of this gap: Superset reports a Codex terminal as working while its native approval dialog is waiting for a response.

   The live control used Superset 1.26.0 and the app-bundled Codex 0.153.4 executable on macOS arm64. Codex ran through Superset's existing wrapper with --ask-for-approval on-request --sandbox read-only. Project-local command hooks recorded lifecycle events and returned {} without deciding permission or updating Superset state.

   The reproduction was a single harmless command:

   Call exec_command with sandbox_permissions=require_escalated to execute:
   python3 -c "print(1234567)"
   Wait for the permission decision.
   

   The native dialog was visibly pending when the host state was sampled. Accepting once executed the command and completed the same conversation. These are observations from one trace; the prolonged wait included an operator interruption and is not a latency benchmark.

   Observation	UTC	Result
   Native PermissionRequest	18:54:29.662	Approval dialog presented
   Host state sampled while dialog remained pending	19:03:54.862	Start
   TUI submitted ExecApproval	19:04:44.969	Accepted once
   Native PostToolUse	19:04:55.021	Command output 1234567
   Native Stop	19:05:14.230	Same conversation; host reached Stop

   The process-scoped TUI log recorded the acceptance with an execution ID, but contained no corresponding approval-prompt record. The live run used the app-bundled binary; a separate npm installation reporting 0.153.4 was version-checked, not exercised in this trace.

   Registering PermissionRequest and clearing it with PostToolUse would not preserve the consumer's semantics. The request hook runs before automatic or user resolution. The post-tool hook observes successful, completed execution. It cannot distinguish actual human attention or clear immediately on every resolution path. These additional paths were source-reviewed, not live-tested here.

   Current main already has the required semantics in app-server. At ad931a45, approval requests follow automatic routing; the existing serverRequest/resolved notification provides matching resolution. The TUI receives these through handle_app_server_event, which bypasses the opt-in session recorder.

   Would maintainers support a fixed, redacted projection of that existing request/resolved pair through CODEX_TUI_RECORD_SESSION, or is another terminal-observer surface preferred? The projection could retain method and thread/request correlation while excluding request content and response decisions. Approval authority would stay with the owning client.

   Focused acceptance cases for that exposure:

   • Each actual approval request and its resolution retain matching identity.
   • Automatic decisions create no false user-attention event.
   • Accept, decline, cancellation, and teardown preserve the existing resolution boundary; accepted work clears before tool completion.
   • Concurrent requests retain distinct identities.
   • Redaction excludes command, directory, reason, input, answer, decision, and error payloads.
   • Disabled or failed recording leaves native approval and execution behavior unchanged.

   The existing session-log tests provide a narrow regression surface. This builds on the app-server lifecycle and relates to #33020 without introducing another approval protocol.

   The control's final response was 1234567, rather than the requested completion marker. Command execution and lifecycle completion are verified; exact-marker compliance is not. Diagnostic excerpts have cost metadata and unrelated account/configuration information removed.
3. hippoley commented on Sep 28, 2026

   

   hippoley

   on Sep 28, 2026 – with ChatGPT Codex Connector

   More actions

   The output-only observer boundary in this proposal looks right to me. One thing I would preserve in the lifecycle shape: "resolved" should not collapse human completion and machine cleanup into the same semantic outcome.

   I hit the same ambiguity while building a small external human-boundary control plane. The failure mode was subtle:

   pending human question
   → timeout / cancellation / policy action
   → generic "resolved"
   → downstream observer concludes "human handled it"
   

   That is enough to create false audit state even if the observer never receives the answer itself.

   A privacy-minimal lifecycle can still distinguish provenance without exposing the decision:

   request/pending
     id=opaque-123
     kind=permission
   
   request/cleared
     id=opaque-123
     cleared_by=human | system | policy | client
     reason=answered | declined | expired | cancelled | replaced | teardown
   

   No command/question text, answer, or approval outcome is required.

   In the prototype I ended up enforcing the same rule at the canonical state layer:

   human decision   -> resolved
   system timeout   -> expired
   runtime cancel   -> cancelled
   policy action    -> policy/system provenance
   

   and a human-only boundary rejects non-human provenance on the normal resolution path.

   Implementation + regression tests, if a concrete shape is useful:
   hippoley/HumanQueue#17

   Separately, for native-host evidence I also found that PermissionRequest alone is not proof of human attention and PostToolUse is too late to represent resolution. That matches the distinction already made in the comment above: the best source is the core-owned request/resolved lifecycle itself.

   So I think the minimal observer contract is strongest if it exposes request identity + lifecycle provenance, while remaining completely output-only and content-free.