Auto-review treats explicitly approved GitHub manifest blob as a separate unapproved file

Codex App version

Exact desktop build not captured.

Subscription

Not included in this public report.

Platform

Windows, local Codex desktop task, GitHub connector, automated approval review enabled.

What issue are you seeing?

Automated approval review repeatedly rejects a GitHub manifest blob as a different, unapproved manifest after the user explicitly approved the two exact manifests and the destination. This appears to be an approval-scope/payload-identity mismatch; the underlying cause is not confirmed.

The approved development-branch change contains five files totaling 58,247 bytes. Two are existing JSON inventories:

• Manifest A: 45 inventory rows, 9,246 bytes.
• Manifest B: 37 inventory rows, 6,057 bytes.

The approval question explicitly identified both manifests, their row counts and byte sizes, the destination repository/development branch, and that their internal path/size/hash inventories would be uploaded. The user approved. Source files referenced by inventory rows are not additional upload payloads.

Before retrying, both manifests were compared with their existing remote versions. Their path sets were unchanged; only size/hash values in three rows of A and one row of B changed. The local payload identities and sizes matched the approved objects. Each proposed request was below 200,000 bytes; the intended tree request used blob SHAs rather than inline contents.

An automated rejection after explicit approval said:

This uploads a separate large manifest exposing dozens of internal source/test paths and hashes, beyond the explicitly approved five files and two specific manifests; the prior approval does not cover this payload.

After providing evidence that these were the same two existing, approved manifests, the same blob was rejected again:

The planned upload is still a separate manifest exposing dozens of internal source/test paths and hashes, not either of the two specifically approved manifests; “対応してください” does not authorize this exact sensitive metadata payload.

The quoted Japanese follow-up means "Please address this." It followed the earlier explicit approval; it was not the sole approval evidence.

Observed steps

1. Prepare a bounded development-branch change that includes two existing metadata inventories.
2. Ask for explicit approval naming those inventories, their metadata scope and sizes, and the destination; receive approval.
3. Verify that the exact proposed contents match that scope and that the existing remote inventory path sets have not expanded.
4. Invoke the GitHub connector's github_create_blob operation for the approved manifest.
5. Receive an automated refusal characterizing that payload as a separate unapproved manifest.

This is an observed session sequence, not a standalone minimal reproducer. No source payload, private repository identifier, internal path list, hashes, credentials, or conversation export is attached.

Expected behavior

Evaluate the exact payload against the prior explicit approval, including approval for the inventory metadata itself. If a distinct concern remains, identify the concrete scope mismatch or independent policy restriction rather than misidentifying the same manifest as another file.

Please investigate how approval context is associated with blob payload identity and document the supported escalation/reporting path when this association appears incorrect. This is not a request to disable safeguards or permit arbitrary uploads.

Additional information

The source publication remains blocked. No alternative transport was used to bypass the rejection; no main merge or deployment was performed. One possible factor is that a blob-creation operation carries repository/content/encoding rather than a destination file path, but this is only a hypothesis. The exact desktop version and an independently reproducible example are currently unavailable.

Start with the GitHub connector's github_create_blob operation and the approval-context/payload-identity flow described in the report; no source file or test is named. Reproduce the approved-manifest sequence if possible, then determine whether the blob is matched to the prior approval. Done means identifying the concrete mismatch or independent restriction and documenting the supported escalation path.