Add permission provenance diagnostics for resumed threads and turns

Problem

Several permission/sandbox reports are hard to triage because the rollout history can show that a turn used a different approval_policy, sandbox_policy, or permission profile, but it is not easy for users or maintainers to tell which config layer, resume/start path, thread setting, or runtime override produced that effective value.

A recent example is #23958, where the maintainer response noted that a missing literal /permissions entry is not enough evidence of a bug because thread/resume and turn/start can apply the current CLI/config permission settings, and each turn persists those values in TurnContextItem. Related goal/resume reports such as #24300 and #24326 show a similar support pattern: the most useful next step is not another policy knob, but a compact way to explain the effective permission context and where it came from.

Today codex doctor --json already helps with install/config/auth/network/local state diagnostics, and recent work added environment, thread inventory, and app-server diagnostics (#24261, #24305, #24311). The remaining gap is permission provenance for a specific thread/turn.

Proposal

Add a bounded, read-only diagnostic path that reports permission provenance for the current or selected thread. Possible shapes:

codex doctor --permissions
codex doctor --thread <thread-id> --permissions
codex doctor --json --thread <thread-id>

The exact CLI shape is flexible. The useful MVP would be a support-safe report that includes:

• effective approval_policy, legacy sandbox_policy, permission profile id/type, filesystem policy, network policy, and cwd/root context;
• whether the value came from the current loaded config, a profile/config layer, CLI flags, persisted thread settings, resume/start overrides, or a runtime override, where that can be determined;
• the last few TurnContextItem permission snapshots for the selected thread, with turn ids/timestamps if available;
• a compact diff when permission-related fields changed between consecutive turns;
• redaction of paths/secrets consistent with existing doctor output.

Why this is useful

This would make permission reports more actionable without changing the permission model itself. It gives maintainers the context they currently have to request manually, and it helps users distinguish expected resume/config behavior from a real silent permission drift bug.

Evidence / related signals

• #23958: maintainer explained that thread/resume and turn/start can carry approval/sandbox settings from active config and that TurnContextItem persists those values, then asked for surrounding JSONL/config evidence.
• #24300: goal auto-continuations can appear to run with downgraded permissions relative to the visible thread state.
• #24326: similar VS Code goal continuation permission mismatch report.
• #24261, #24305, #24311: recent doctor improvements show that read-only, support-oriented diagnostics are an accepted direction for hard-to-triage local-state issues.

MVP scope

Keep this diagnostic-only:

• no permission repair;
• no automatic migration;
• no new approval behavior;
• no broad JSONL dump by default;
• no secrets or full config contents in the support report.

Possible validation

A focused test could construct a short rollout history with two TurnContextItem records that differ in approval_policy / permission profile, then assert that the diagnostic reports the effective values and the field-level change. A separate config-layer test could verify that the current active config/profile is identified without exposing unrelated config contents.

Open questions

• Should this live under codex doctor, codex debug, or codex thread inspect?
• Should the default target be the current thread, the most recent thread in the cwd, or require an explicit thread id?
• How much provenance can be determined accurately today from ConfigLayerStack and persisted thread settings without adding new source metadata?

Duplicate check performed

I searched open and closed issues/PRs for combinations of permission provenance, permission profile cause, sandbox provenance, effective permissions doctor, configuration provenance permissions, turn_context approval_policy, SessionConfigured permission profile, resume permission profile, and config layer stack permissions. I found related bug reports (#23958, #24300, #24326) but no existing issue focused on a read-only permission provenance diagnostic.