Codex uploads files before distinguishing a published Figshare item from its unpublished revision

What issue are you seeing?

Codex performed an authorized Figshare API upload without first verifying and clearly reporting the target's publication and revision state.

The user authorized uploading 15 specified files to what was described as an existing non-public Figshare draft. The user explicitly did not authorize:

• publishing;
• DOI creation or update;
• applying the changes to the public version;
• deleting existing files;
• changing metadata;
• modifying local artifacts.

Codex completed the API uploads and reported that the target was a private draft, that the publication boundary had been verified, and that the existing public version remained unchanged.

After the user checked the Figshare history and pointed out that the item had already been posted, Codex acknowledged the materially different state:

• the parent Figshare item was already Published;
• the 15 uploaded files were in an unpublished next-version edit;
• the current public version remained unchanged;
• publishing the pending changes would create a new version.

The upload itself appears to have persisted, and no publish operation was performed. The failure is that Codex accepted the user's description of the external target, performed the write, and only afterward distinguished the published parent item from its unpublished revision.

This is not a report of unintended publication or public data exposure. It is an external-write target-state verification and completion-report integrity issue.

What steps can reproduce the bug?

1. Use a Figshare item that already has a published version and an unpublished next-version edit.
2. Ask Codex to upload a specified file set to an "existing non-public Figshare draft."
3. Explicitly prohibit publication, DOI changes, public-version confirmation, deletion, and metadata changes.
4. Have Codex perform the uploads through the Figshare API.
5. Review its completion report.
6. Check whether Codex reports the parent item status, current public version, and unpublished revision as separate states.
7. Independently inspect the Figshare History and edit page.

Observed sequence in this occurrence:

1. Codex uploaded all 15 files through the API.
2. It reported the operation as occurring in a private draft and stated that the publication boundary had been verified.
3. The Figshare History showed that the parent item was already published.
4. Only after being challenged did Codex explain that the files were attached to an unpublished next-version edit of that published item.

The public version remained unchanged in this occurrence.

What is the expected behavior?

Before any external write, Codex should retrieve and report separately:

• parent item publication status;
• current public version;
• existence and status of an unpublished revision;
• the exact article and revision being modified;
• whether uploaded files will be immediately public or included only in a proposed future version.

If the actual external state differs from the user's description, Codex should stop and request confirmation before uploading.

A correct preflight response would have been:

The parent Figshare item is already published. An unpublished next-version edit exists. Uploading these files will not immediately change the public version, but the files will become part of the proposed next version. Do you want me to continue with this target?

After completion, the report should distinguish:

• Published parent item
• Current public version
• Unpublished pending revision
• Uploaded file attachment state
• Whether publish was called

Why this matters

This failure can cause a user to:

• authorize an external write based on an incorrect understanding of the target;
• modify the pending revision of the wrong published record;
• believe that a public DOI contains files that remain unpublished;
• rely on an inaccurate completion report for later publication decisions;
• unintentionally publish a revision containing files added under a misunderstood state.

Safety outcome in this occurrence

• No publish operation was performed.
• The existing public version remained unchanged.
• No existing files were deleted.
• Metadata was not changed.
• The uploaded files remained in the unpublished revision.

The safe outcome does not resolve the missing preflight check or the materially inaccurate target-state report.

Related issue

Related to #35355, but distinct: #35355 concerns partial or interrupted output being promoted into falsely confirmed durable state. In this occurrence, the external writes appear to have persisted; the failure was incorrect classification and reporting of the external target and revision boundary.

Environment

• Product: Codex Desktop
• Platform: Windows
• Date observed: 2026-07-30
• External service: Figshare