Historical Codex task evidence: missing repository attribution and execution/audit traceability

Summary

A preserved historical Codex Cloud task now contains directly observable workspace-level execution evidence, including Git history, specific source changes, and Logs-tab content referencing GitHub webhook deployment, AWS CDK deployment, GitHub OIDC, and short-lived credentials. However, the task UI does not expose enough repository/audit metadata to reliably bridge the Codex workspace to external GitHub events or determine actor/environment provenance without separate administrative/compliance records.

This report requests improved inspectability and traceability for historical Codex Cloud tasks. It does not assert that an external GitHub push, PR, workflow, AWS deployment, or physical-device action occurred.

Historical task

Task ID:
task_e_6aa14dca1fa883278dff083c48211749

Review title:
Add webhook traceability, PHP modernization, and evidence report

Observed workspace:
/workspace/dl909-ai-private

Observed base/main commit:
62cfb0e4fbb077a2238a3f9aa6f830ac29586261

Observed task-result / aggregate commit:
5dfaea834d153fc1a80fff47cb4ca1778481500d

Observed aggregate change set:
15 files changed, 449 insertions, 2 deletions

Example directly associated file:
lib/traceability-webhook-evidence-stack.ts

The preserved task record also shows task-associated Git history and complete diffs.

Logs-tab evidence

The authenticated task's Logs tab displays historical patch/diff material containing:

• GitHub repository webhook configuration instructions
• pull_request
• pull_request_review
• check_suite
• workflow_run
• AWS CDK deployment instructions
• GitHub OIDC recommendation
• short-lived credential recommendation
• warning against long-lived AWS access keys in repository secrets
• an explicit provenance section for an upstream traceability starter

These observations establish that the instructions/content existed in the historical task. They do not establish that any webhook, GitHub Actions workflow, OIDC exchange, push, PR, or AWS deployment actually occurred.

Current evidentiary stopping point

The strongest currently supportable chain is:

Historical Codex task
        ↓
/workspace/dl909-ai-private
        ↓
historical Git activity + source changes
        ↓
5dfaea834d153fc1a80fff47cb4ca1778481500d
        │
        ╳
        ↓
external GitHub repository / push / PR / workflow

The missing bridge is external repository identity and event-level auditability.

Why this matters

A historical task can expose substantial execution evidence without exposing enough metadata to answer basic audit questions such as:

• Which external repository was associated with the task?
• What remote/origin URL was in effect?
• Which branch and commit were checked out by the environment?
• Which Codex environment ID produced the task?
• Who created the task?
• Which commands were executed, by which actor/tool, and with what exit codes?
• Was agent internet access enabled for the effective session?
• Did any push, PR, workflow, webhook, or cloud-authentication action occur?
• Was a Remote Control client involved?

This makes it difficult to distinguish workspace-local execution from external side effects.

Relevant documented administrative/compliance sources

Current OpenAI Programmatic Admin Platform documentation describes evidence sources capable of carrying some of the missing metadata, including:

• Codex task records with created_by_id
• Codex environment records
• environment repo_map containing repository URL / branch / commit
• CODEX_LOG
• CODEX_SECURITY_LOG
• AUDIT_LOG
• AUTH_LOG
• APP_AUTH_LOG
• Remote Control environment/thread/client records

The issue is not that these concepts are undocumented. The problem is that historical task review surfaces do not provide enough directly inspectable linkage to them, and users may not have administrative/compliance access.

Requested improvements

Please consider exposing a stable read-only execution/audit panel for each Codex Cloud task containing at least:

1. Task ID and environment ID
2. Task creator / initiating identity
3. Repository identity and canonical remote URL
4. Base branch and checked-out commit SHA
5. Effective network-access state
6. Setup-script versus agent-phase execution boundaries
7. Command/tool execution history with timestamps, actor/tool identity, stdout/stderr, and exit codes
8. Resulting file/diff/commit identifiers
9. External side-effect events, if any, such as push, PR, workflow, webhook, or cloud-authentication activity
10. Stable export/download of the above for incident response and reproducibility

Forensic boundary

This report deliberately separates capability from demonstrated execution:

artifact presence
→ provenance
→ configuration
→ capability
→ execution
→ actor attribution
→ execution outcome
→ target attribution
→ authorization
→ causation

No claim is made here that the historical task pushed to GitHub, created a PR, executed GitHub Actions, deployed to AWS, or interacted with a physical iPhone. Those remain unestablished without the missing bridge evidence.

Related prior report

This is distinct from openai/codex issue #43328, which concerns hourly automation lacking a visible next run / inspectable execution history. The common theme is auditability, but this report concerns historical Codex Cloud task provenance and external-side-effect traceability.

No implementation files or tests are named. Start by reviewing the documented Codex task, environment, repository-map, and audit-log records, then compare the historical review surface with related issue #43328. Done means a stable read-only panel and export expose the requested task, repository, execution, identity, side-effect, and provenance metadata.