[Bug]: Codex permission approval drops structured requested rights from the user-facing artifact #26092

Summary

Source inspection of T3 v0.1.3 (d2c440312e5f39d59827ed466838a623516454d6) shows that item/permissions/requestApproval drops the structured requested permissions when constructing the user-facing approval artifact, while acceptance returns the original permission object to Codex.

This is a source-confirmed presentation/data-flow finding, NOT an executed end-to-end approval reproduction or a claim of exploitation. Our installation audit concerned T3 0.1.2 with Codex CLI 0.164.0 on Linux; its permission-request feature flags were reported disabled. We did not enable them or grant permissions to reproduce this.

Source trace

• providerRequestKindFromPermissions and permissionsResponseFromDecision: classification reduces permissions to file-change, file-read, or command. Accept returns the original permissions with turn/session scope.
• permissions request handler: buildApprovalRequestArtifacts receives requestKind and optional payload.reason, but not payload.permissions.
• approval panel: renders detail/reason and a generic kind label; the omitted structured permissions cannot be reconstructed reliably from agent-authored reason text.

Expected behavior

Display the actual requested filesystem entries/access modes and network permission, separately from the agent's explanation. Clearly show turn versus session grant lifetime before approval. Preserve the structured request through persistence/reconnect. Do not imply a network grant is loopback-only when the protocol only says enabled=true.

Suggested regression test (not executed here)

Feed the adapter a synthetic permissions request with network enabled and a neutral reason; assert that the durable approval and rendered card explicitly display that network permission. Repeat for filesystem and mixed requests, missing reason, decline, turn acceptance and session acceptance. Verify the displayed grant matches the returned grant.

Scope

This report does not ask to enable experimental features by default, weaken the sandbox, or change existing permissions. It is separate from network-policy inheritance (#13987 / discussion #6976). No live exploit, bypass or root cause for unrelated spawnSync EPERM is claimed.