Bug: browser attachment runs can fall back to Enter after upload timeout instead of failing before send

[HeMuling]

Summary

In browser mode with ChatGPT attachments, local runs can get into a split-brain state between attachment completion and send readiness:

• waitForAttachmentCompletion waits on one readiness contract
• attemptSendButton later uses a different one
• when attachment confirmation times out, local browser mode clears attachmentNames and continues anyway
• submit can then fall back to Enter, leaving the prompt unsent and eventually failing with Prompt did not appear in conversation before timeout (send may have failed)

This appears distinct from #10: in this repro the prompt never commits, and the log shows Submitted prompt via Enter key, not Clicked send button.

Environment

• oracle HEAD: ab116c0
• browser mode with manual-login profile
• model: gpt-5.4-pro
• --browser-attachments always
• reproducible with two small text files

Reproduction

Example command:

pnpm run oracle -- --engine browser \
  --browser-manual-login \
  --browser-port 9333 \
  --browser-reuse-wait 10s \
  --browser-profile-lock-timeout 300s \
  --model gpt-5.4-pro \
  --browser-attachments always \
  --prompt "Attachment send race reproduction. Reply exactly with OK." \
  --file /tmp/a.txt \
  --file /tmp/b.txt \
  --verbose

1. Reuse a signed-in ChatGPT browser profile.
2. Force attachment upload mode with two small files.
3. Observe verbose logs during the attachment wait and send phases.

Failure log excerpt

This is the failing sequence from the real repro log:

Uploading attachment: ../../../tmp/oracle-race.aKIUsa/a.txt
Attachment queued (UI anchored, file input confirmed)
Uploading attachment: ../../../tmp/oracle-race.aKIUsa/b.txt
Attachment queued (UI anchored, file input confirmed)
Attachment wait state: {"state":"disabled","uploading":false,"filesAttached":true,"attachedNames":["remove file","remove file","remove file"],"inputNames":["b.txt"],"fileCount":0}
...
Attachment upload timed out while waiting for ChatGPT composer to become ready.
[browser] Attachment upload timed out after 80s; continuing without confirmation.
Submitted prompt via Enter key
Prompt commit check failed; latest state: {"baseline":0,"userMatched":false,"prefixMatched":false,"lastMatched":false,"hasNewTurn":false,...}
Failed to complete ChatGPT run: Prompt did not appear in conversation before timeout (send may have failed)

Actual behavior

The run waits in a disabled-button state until attachment confirmation times out, then local browser mode continues without confirmation and later falls back to Enter.

Expected behavior

For attachment submissions Oracle should either:

• wait until the same composer is actually send-ready and click send, or
• fail fast with an explicit attachment/browser automation error

It should not degrade into a plain-text Enter submit after attachment confirmation fails.

Root cause

The attachment lifecycle and send lifecycle currently use different readiness contracts:

• waitForAttachmentCompletion in src/browser/actions/attachments.ts
• attemptSendButton in src/browser/actions/promptComposer.ts
• local browser mode in src/browser/index.ts catches attachment timeout, drops attachmentNames, and keeps going

That violates the invariant that an attachment submission must not enter the send path unless the same composer has stable attachment evidence and a clickable send button.

Fix candidate validation

The candidate fix in PR #116 was validated with a live browser run. The repaired flow now waits for stable attachment evidence, then waits for the same composer to become send-ready before clicking send:

Uploading attachment: ../../../tmp/oracle-attach-min.1yYKNT/oracle-live-1773660483-12767-verify-note.txt
Attachment queued (UI anchored, file input confirmed)
Attachment wait state: {"state":"disabled","uploading":false,"filesAttached":true,"fileCount":0,"attachmentUiCount":1,"attachedNames":["remove file"],"inputNames":["oracle-live-1773660483-12767-verify-note.txt"],"attachedMatch":false,"inputMatch":true,"fileCountSatisfied":false,"attachmentUiSatisfied":true}
All attachments uploaded
Attachment send readiness: {"state":"disabled","uploading":false,"filesAttached":true,...}
Clicked send button
Verified attachments present on sent user message
Answer:
OK

Related

• #64 tracks broken attachment uploads more generally
• #10 tracks prompt-commit false negatives after a successful send
• PR #56 already tightened upload/send-button handling in a nearby area
• PR #31 handled newer ChatGPT attachment chip behavior
• PR #60 fixed duplicate attachment attempts