Browser attachments timeout when ChatGPT renames uploaded files (01.jpg → 01(5).jpg)

[dougvk]

Summary

With --engine browser --browser-attachments always, Oracle can time out waiting for attachments even after ChatGPT has accepted the files and enabled Send.

ChatGPT renames colliding uploads (01.jpg → 01(5).jpg, document.md → document(20260818-145702).md). Oracle's chip/name matcher still looks for the original basename. For short names such as 01.jpg, 01 is shorter than the 6-character extensionless fallback, and 01.jpg is not a substring of 01(5).jpg, so the wait never completes.

Increasing --browser-attachment-timeout does not help. The files are already in the composer.

This is distinct from #221 / #214 (Send never becomes ready) and #275 (file input has the original name but no chip evidence). Here the chips exist, Send is enabled, and the original names are gone because ChatGPT renamed them.

Reproduced on @steipete/oracle@0.18.0 against a signed-in ChatGPT browser session.

Environment

• Oracle: 0.18.0
• Engine: browser, attach to an already-running Chrome DevTools endpoint
• --browser-attachments always
• ChatGPT composer shows an enabled button[data-testid="send-button"]

Minimal reproduction

Use short, colliding names (the second run against the same composer is enough):

mkdir -p /tmp/oracle-rename-repro
printf 'Synthetic diagnostic text. No secrets.\n' > /tmp/oracle-rename-repro/document.md
# any small JPEG is enough; filename is the point
printf '\xff\xd8\xff\xd9' > /tmp/oracle-rename-repro/01.jpg

npx -y @steipete/oracle@0.18.0 \
  --engine browser \
  --model gpt-5.6-sol \
  --browser-attachments always \
  --force \
  --slug oracle-rename-repro-one \
  -p "Diagnostic only. Reply exactly OK." \
  --file /tmp/oracle-rename-repro/document.md \
  --file /tmp/oracle-rename-repro/01.jpg

Repeat the same command (same filenames, same ChatGPT composer). The second run is the reliable fail: ChatGPT keeps the previous 01.jpg collision and labels the new chip 01(5).jpg / document(<timestamp>).md.

Actual

Oracle reports one of:

ERROR: Attachments did not finish uploading before timeout.
User error (browser-automation): Attachments did not finish uploading before timeout.

or

ERROR: Attachments never reached a clickable send button after 45s; tune --browser-attachment-timeout.

After the failure, the ChatGPT composer already has:

• a chip like Remove file 1: document(20260818-145702).md
• a chip like Remove file 2: 01(5).jpg
• Send enabled
• no uploading/busy state
• no alert

The hidden input[type=file] may still list 01.jpg while the visible chip uses the renamed label. waitForAttachmentCompletion / matchesExpected() require attachedNames to include the original basename (or a ≥6-char stem). 01.jpg matches neither 01(5).jpg nor a stem of length ≥6.

A control run with unique long names (synthetic-post-document.md + synthetic-post-image-01.jpg) finishes in ~20s on the same session.

Longer names such as document.md can still pass after rename because the stem document is ≥6 characters and is a substring of document(20260818-145702).md. That is why markdown-only uploads often succeed and adding 01.jpg fails.

Expected

Treat ChatGPT's collision rename as the same file:

• name.ext should match name(N).ext and name(<digits>).ext
• readiness should succeed when chips exist, upload is idle, and Send is enabled, even if the visible label is a collision rename

Workaround for callers: give every --file a unique basename longer than 6 characters. That should not be required once Oracle recognizes the renamed chip.

Suggested matcher

In src/browser/actions/attachments.ts (matchesExpected / equivalent chip matching), accept:

^<stem>(\(\d+\))?\. <ext>$

case-insensitively, in addition to the current includes / ellipsis / ≥6-char stem checks.

No logs, cookies, account data, or conversation content are included in this report.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 25, 2026, 1:49 AM ET / 05:49 UTC.

Summary
Keep open: current main still rejects the reported short collision-renamed attachment labels, and the formally linked open PR owns the focused repair.

Reproducibility: yes. —current main’s two matching paths directly reject 01(5).jpg for expected 01.jpg, matching the reported browser workflow; a live signed-in ChatGPT run was not needed to establish the source path.

Root-cause cluster
Relationship: canonical
Canonical: #393
Summary: This issue is the canonical report for the short collision-renamed attachment-name matcher defect; one open PR is its candidate fix.

Members:

• fixed_by_candidate: fix(browser): match ChatGPT collision-renamed attachment names #401 - The PR explicitly targets collision-renamed ChatGPT attachment names and formally links to this issue.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
The explicitly linked open PR already owns the bounded implementation, so a new repair PR would duplicate contributor work.

Review details

Best possible solution:

Land a narrowly bounded collision-rename matcher across every existing attachment readiness path, with regression cases using real chip text for short names and negative near-matches.

Do we have a high-confidence way to reproduce the issue?

Yes—current main’s two matching paths directly reject 01(5).jpg for expected 01.jpg, matching the reported browser workflow; a live signed-in ChatGPT run was not needed to establish the source path.

Is this the best way to solve the issue?

Yes—the linked repair direction is the narrow maintainable fix if it preserves filename boundaries and extensions across all readiness matchers rather than relaxing generic stem matching.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A broad stem-only match could accept a different attachment such as 001.jpg; the repair should retain full-name boundaries and extension checks.

Codex review notes: model internal, reasoning high; reviewed against 79e483bd9dc8.

Label changes

Label justifications:

• P1: The defect blocks browser-engine attachment submissions even after ChatGPT has accepted the files and enabled Send.
• impact:message-loss: The attachment readiness failure prevents the intended file-bearing prompt from being delivered.

Evidence reviewed

What I checked:

• Current attachment-completion defect: Current main accepts an attached name only when it contains the full original name or a stem of at least six characters; 01(5).jpg satisfies neither condition for expected 01.jpg. (src/browser/actions/attachments.ts:1602, 79e483bd9dc8)
• Current send-readiness defect: The composer readiness matcher separately requires a collision-renamed stem to be at least four characters, so the two-character stem 01 is rejected there too. (src/browser/actions/promptComposer.ts:431, 79e483bd9dc8)
• Current-main provenance: The matching files have no diff from v0.17.3 through current main, so the unsupported short-name path remains present at the reviewed revision. (src/browser/actions/attachments.ts:1608, 79e483bd9dc8)
• Feature-history routing: Blame attributes the current matcher lines to Peter Steinberger’s release snapshot commit, providing the available history signal for this shallow checkout. (src/browser/actions/attachments.ts:39, 6b17e6db0cae)
• Open implementation owner: The provided GitHub context shows fix(browser): match ChatGPT collision-renamed attachment names #401 is open, cleanly mergeable, explicitly targets this behavior, and uses formal closing syntax for this issue. (928d98023eec)

Likely related people:

• Peter Steinberger: Current attachment and composer matcher lines trace to the release snapshot authored by Peter Steinberger. (role: recent area contributor; confidence: medium; commits: 6b17e6db0cae; files: src/browser/actions/attachments.ts, src/browser/actions/promptComposer.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.