fix(browser): keep attachment sends in the active chat

[oraclexing]

Keep attachment uploads and sends in their original ChatGPT context. The maintainer integration preserves upload-progress blocking and per-file evidence from main, including filename-less image previews, while refusing unrelated plus/send controls and context switches before each file assignment and prompt send.

Native file input events and renderer DataTransfer assignment validate the pre-upload page identity before application handlers can consume bytes. Exact plus and send activation recheck the original button, focus, context, and send readiness at event delivery. Attachment prompt editing and fallback writes are bound to the original renderer/editor, with guarded beforeinput/input events; a document replacement cannot redirect a delayed CDP text-insertion command. A possibly dispatched key is never replayed after transport failure. Same-conversation URL rewrites remain valid; Work identities and other conversations/projects are rejected. Label-based Work checks are scoped to composer controls; unrelated selected sidebar items and unknown localized labels are not treated as proof of Work mode.

The actual built CLI and isolated real Chrome reproduce the main-branch project-switch failure, then exercise local/remote uploads, first/between-file context switches, delayed send/assignment transitions, plus focus races, localized Chat and Work machine values, missing exact controls, focus/readiness recovery, byte-for-byte filename-less images, prompt focus/input races, and textarea/contenteditable editing with forced fallback. The existing three-file progress/hash proof also remains required. Linux CI runs the CLI fixture. Full-suite results, exact-head CI, and branch review are recorded in the proof comment.

File delivery is authorized only while the captured context matches. If provider code changes context inside its own handler after receiving the File, post-handler checks stop further Oracle actions and clear the DOM selection; they cannot revoke copied File objects or cancel provider requests already queued. The fixture records final DOM cleanup, not proof that the handler never accessed the file.

Unproven here: fresh signed-in ChatGPT attachment/menu/Work DOM variants and framework handling of renderer editing commands, localization without stable mode identity, account-specific upload handling, and actual provider processing of the files. These fixture results do not establish a fix for #463's distinct current signed-in bundle visibility report.

Thanks @oraclexing. Deferred changelog line after landing: Browser: keep attachment uploads and sends in the original chat, validate exact controls at delivery, and stop context/focus races without replaying a dispatched action; thanks @oraclexing.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 7, 2026, 11:42 AM ET / 15:42 UTC.

ClawSweeper review

What this changes

The PR binds browser attachment uploads, prompt editing, and submission to the original ChatGPT context, adds guarded button activation, and expands browser regression coverage.

Merge readiness

⛔ Blocked before merge - 3 items remain

The PR remains useful and the earlier source-level findings are addressed. Current signed-in compatibility remains unresolved; the repository profile also prohibits automatic closure.

Priority: P1
Reviewed head: beb7f7f20972ff2a09be5f4da6478210852472be
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A coherent repair with substantial browser evidence and no remaining concrete finding, subject to signed-in compatibility acceptance.
Proof confidence	🐚 platinum hermit (4/6)	Sufficient (logs): The captured built-CLI/real-Chrome evidence exercises the production upload, editing, and send owners and reports successful single commitment plus refusal after context switches. This supports the controlled browser boundary; current signed-in provider compatibility remains a separate gate.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (logs): The captured built-CLI/real-Chrome evidence exercises the production upload, editing, and send owners and reports successful single commitment plus refusal after context switches. This supports the controlled browser boundary; current signed-in provider compatibility remains a separate gate.
Evidence reviewed	10 items	Repository policy and identity: The origin remote identifies steipete/oracle. The root AGENTS.md was read completely; no nested AGENTS.md or maintainer-notes directory was found. Browser smoke guidance informed the compatibility assessment. Original context reaches both production paths: Local and remote browser runs capture the pre-upload URL, validate it between files, and pass it through the provider to prompt submission. The introduced delta was inspected against the host-verified merge base. Earlier navigation and staging findings addressed: Context validation compares origin and conversation ID, or normalized landing path, and rejects recognized Work state. Prompt staging now uses a renderer-local guard retaining the original editor, checks input events, and stops after ambiguous insertion acknowledgement.
Findings	None	None.
Security	None	None.

How this fits together

Oracle’s browser engine sends user prompts and local files through a signed-in ChatGPT page. Its attachment pipeline prepares files, checks composer readiness, submits the prompt, and verifies that a user turn committed.

flowchart TD
  A[Prompt and local files] --> B[Capture original chat context]
  B --> C[Guard file assignment]
  C --> D[Verify upload evidence]
  D --> E[Guard prompt editing]
  E --> F{Context and exact send button ready?}
  F -->|Yes| G[Submit once and verify committed turn]
  F -->|No| H[Stop with diagnostics]

Loading

Decision needed

Question	Recommendation
Should exact-control attachment sending become the default before current signed-in fresh and existing profiles demonstrate compatibility?	Validate signed-in compatibility first: Hold landing until current-head evidence shows ordinary Chat commitment and Work refusal for fresh and existing signed-in profiles.

Why: The branch intentionally removes permissive attachment activation paths; passing fixtures cannot determine acceptable disruption to existing signed-in workflows.

Before merge

• Resolve merge risk (P1) - Existing attachment workflows may now stop when ChatGPT lacks the exact send control or its editor does not accept the renderer editing path; synthetic fixtures do not establish compatibility for fresh and existing signed-in profiles.
• Complete next step (P2) - Resolve the signed-in compatibility gate with current-head fresh/existing-profile evidence and maintainer acceptance, or explicit maintainer acceptance of the documented limitation.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and validation growth	Production +902 net lines; tests and proof harnesses +1,481 net lines	Production growth implements context and event-delivery guards, with substantial regression and real-browser harness coverage.

Merge-risk options

Maintainer options:

1. Establish signed-in compatibility (recommended)
   Retain the safety guards and provide current-head signed-in commitment and Work-refusal evidence before landing.
2. Accept narrower supported behavior
   A maintainer may explicitly accept controlled failures on unsupported composer variants with clear user-facing documentation.

Technical review

Best possible solution:

Keep context-bound, single-dispatch attachment handling while establishing signed-in upgrade compatibility and obtaining maintainer acceptance of deliberate fail-closed behavior.

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

Yes: the current-main coordinate path and the supplied real-Chrome project-switch comparison establish a concrete mechanism; this read-only review did not execute it.

Is this the best way to solve the issue?

Yes for the context-safety repair: checks at file delivery, editing, and submission address the actual boundaries while retaining attachment evidence; signed-in compatibility still needs resolution.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 54dafa78fe6f.

Labels

Label justifications:

• P1: The repair addresses attachment consultations entering the wrong ChatGPT context or failing to commit.
• merge-risk: 🚨 compatibility: Exact-control requirements and renderer editing can stop existing attachment workflows on unverified signed-in UI variants.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (logs): The captured built-CLI/real-Chrome evidence exercises the production upload, editing, and send owners and reports successful single commitment plus refusal after context switches. This supports the controlled browser boundary; current signed-in provider compatibility remains a separate gate.
• proof: sufficient: Contributor real behavior proof is sufficient. The captured built-CLI/real-Chrome evidence exercises the production upload, editing, and send owners and reports successful single commitment plus refusal after context switches. This supports the controlled browser boundary; current signed-in provider compatibility remains a separate gate.

Evidence

What I checked:

• Repository policy and identity: The origin remote identifies steipete/oracle. The root AGENTS.md was read completely; no nested AGENTS.md or maintainer-notes directory was found. Browser smoke guidance informed the compatibility assessment. (AGENTS.md:1, beb7f7f20972)
• Original context reaches both production paths: Local and remote browser runs capture the pre-upload URL, validate it between files, and pass it through the provider to prompt submission. The introduced delta was inspected against the host-verified merge base. (src/browser/index.ts:1720, beb7f7f20972)
• Earlier navigation and staging findings addressed: Context validation compares origin and conversation ID, or normalized landing path, and rejects recognized Work state. Prompt staging now uses a renderer-local guard retaining the original editor, checks input events, and stops after ambiguous insertion acknowledgement. (src/browser/actions/attachmentPrompt.ts:13, beb7f7f20972)
• Still necessary on current main: Pinned main still sends attachments through the stable-coordinate path; the PR introduces the exact-button and delivery-time context guards. No supplied merged related PR owns this repair. Reading the v0.18.0 attachment blob failed because the object was unavailable, so release inclusion was not independently established. (src/browser/actions/promptComposer.ts:610, 54dafa78fe6f)
• Production-path fixture coverage: The captured PR body reports actual built-CLI runs using real Chrome and local/remote CDP transport. The inspected harness checks committed output, byte integrity, zero editor-Enter submissions, context-switch refusal, focus recovery, and guarded editing fallbacks. Its provider pages are synthetic. Provider-handler context changes establish subsequent cleanup, not revocation of File objects already delivered. (scripts/attachment-cli-proof.mjs:225, beb7f7f20972)
• Proof identity and compatibility limits: The supplied snapshot, sourceRevision 3ae11296a80037c144c01601361e5ae001930ccecb2c0e729bcfcf4d8c0b4065, explicitly leaves fresh signed-in DOM variants and framework editing behavior unproven. The browser-accessible PR page returned an older body with signed-in image completion evidence; it was treated as historical evidence, not substituted for the pinned snapshot. The additional current proof-comment transcript could not be retrieved. See fix(browser): keep attachment sends in the active chat #431. (beb7f7f20972)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Lu Wang: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Provide current-head signed-in Chat commitment and Work-refusal evidence for fresh and existing profiles, with private details redacted.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (8 earlier review cycles)

• reviewed 2026-08-28T13:26:55.923Z sha 7b753df :: needs changes before merge. :: [P1] Handle project-scoped conversation URLs in the navigation guard
• reviewed 2026-09-02T01:17:56.140Z sha 7d5a052 :: needs changes before merge. :: [P1] Recheck navigation immediately before prompt submission
• reviewed 2026-09-02T01:59:13.726Z sha 13b4d5f :: needs real behavior proof before merge. :: none
• reviewed 2026-09-02T02:44:08.877Z sha 13b4d5f :: needs changes before merge. :: [P1] Reject landing-context navigation without a conversation ID
• reviewed 2026-09-02T03:31:26.002Z sha 79c364f :: needs maintainer review before merge. :: none
• reviewed 2026-09-07T15:06:50.545Z sha f4647e5 :: blocked before merge. :: none
• reviewed 2026-09-07T15:14:59.234Z sha f4647e5 :: blocked before merge. :: [P1] [P1] Bind prompt staging to the original attachment context
• reviewed 2026-09-07T15:33:17.404Z sha beb7f7f :: blocked before merge. :: none

[oraclexing]

Updated the PR body with exact-head signed-in chatgpt_image completion evidence and real-Chrome delayed-navigation refusal evidence.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

[oraclexing]

Addressed the remaining landing/project-context P1 on exact head 79c364f0f44bb4034f939657492c18f08f2bf069. Added canonical non-conversation path binding, focused root→project and project A→B regressions, a real-Chrome delayed project-switch refusal with zero send/input events, and a fresh signed-in chatgpt_image completion on the exact head. PR body has the full evidence.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/33587483175
• Updated: 2026-09-02T03:33:47.372Z

[steipete]

Maintainer proof for head beb7f7f.

Contributor history is preserved. Current main was integrated, then a follow-up commit closed prompt-staging and post-event context gaps found during review. No changelog delta is included in this branch.

Validation: pnpm test passed 2,164 tests (45 skipped); pnpm lint, pnpm build, and pnpm docs:check passed. Local and final branch autoreview through P2 are clean. Exact-head CI: https://github.com/steipete/oracle/actions/runs/34138528924 — all four jobs succeeded.

Real execution: node scripts/attachment-cli-proof.mjs passed all 27 current-candidate cases through the actual built CLI and isolated real Chrome. The matrix covers local/remote files, context switches before/between assignments, native/renderer assignment and post-handler rollback, exact plus/send focus and readiness, Work machine values, unrelated selected Work labels, same-conversation rewrites, filename-less image bytes, and prompt editing/fallback in textareas and contenteditable editors. Prompt focus, beforeinput, and application input-handler navigation leave zero staged characters and zero sends; file-handler navigation clears the newly assigned selection and sends nothing.

Two controlled before/after observations support the root-cause repairs. The main-branch build sent after a project switch; the candidate refuses that switch. A built-CLI control using the pre-fix f4647e5 prompt-staging module left all 61 prompt characters in the wrong context even though send was refused; the current renderer-bound editing path leaves zero. The existing three-file progress/hash proof also passed both routes with exactly one trusted send and no editor Enter. The expanded actual-CLI matrix runs in Linux CI.

File delivery is authorized only while the captured context matches. If provider code changes context inside its own handler after receiving the File, post-handler checks stop further Oracle actions and clear the DOM selection; they cannot revoke copied File objects or cancel provider requests already queued. The fixture records final DOM cleanup, not proof that the handler never accessed the file.

Limits: no fresh signed-in ChatGPT attachment/menu/Work DOM proof, no verification of its current framework handling of renderer editing commands, no complete localization guarantee without stable identity, and no account-specific upload/provider-processing proof. All pages/files here are synthetic. These checks do not establish a fix for #463's separate signed-in bundle-visibility report.

The deferred release-note line is in the PR body. Ready for orchestrator review; not merged.