Harvest can capture another concurrent run's answer and report it as this run's completed result

[postoso]

Version: oracle 0.17.3, browser engine (-e browser --browser-manual-login), persistent Chrome profile, GPT-5.6 Sol at Pro thinking time

When two runs are launched against the same persistent Chrome profile close together, a run can bind to another run's conversation. The harvest then captures that other run's answer and stores it under this run's slug. The session reports completed, the archived transcript passes validation, and nothing in the output indicates the answer belongs to a different question.

What I observed

Session slug oracle-trigger-rewrite-contract-review. Its archived transcript at ~/.oracle/sessions/<slug>/artifacts/transcript.md contains:

• ## Prompt — a request to review an operating-reference document for a browser-automation lane. Correct; this is the prompt that was sent.
• ## Answer — a twenty-section review of an entirely different subject: a database schema-recovery runbook, discussing Dolt commits, schema_migrations rows, and backup semantics. It has no relationship to the prompt above it.

A second run against the same profile that evening was reviewing exactly that database runbook. Its answer is what landed in this session's transcript.

The run's own header reported:

Status: completed
Response: status=completed
Artifacts:
- Browser transcript — .../artifacts/transcript.md (36.5 KB) sha256=7ccd3dd9d23b… validation=ok

So validation=ok and sha256 are present and correct. They validate that the file transferred intact, not that its contents answer the prompt. Both signals a caller would reach for to check success are green.

Why this is worth a guard

Every other failure mode in this area is detectable by counting or by an error. This one is not. The output is a well-formed, high-quality answer to a question, so it survives a skim by a human and passes any automated check that looks at status, exit code, size, or hash. Where a caller is chaining oracle output into further automated work, a topically adjacent answer can be acted on before anyone notices.

Suggested direction

I do not have a deterministic reproduction; it requires two runs racing on one profile and I hit it once. But the failure seems addressable without reproducing the race:

• Bind and verify a conversation id per run. If the harvest is scoped to a conversation id the run itself established, capturing a different conversation's content becomes detectable rather than silent.
• Treat a mismatch as an error, not a completion. Right now the run reports completed.
• A caller-side marker also works and needs no server changes. I now open every prompt with an instructed echo token and refuse to trust a harvested answer whose first line does not carry it. That has been effective, but it is a workaround each caller has to invent, and it only helps callers who know to do it.

Happy to dig up more detail from the archived session if useful. The transcript is still on disk.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 23, 2026, 1:58 PM ET / 17:58 UTC.

Summary
Keep open for maintainer investigation. Current and v0.17.3 source already contain conversation-ID capture guards and isolated shared-profile tabs, but the reported silent cross-run result needs paired session evidence to locate a remaining bypass safely.

Reproducibility: no. The reporter observed the race once but provided no deterministic paired-run trace, and current source already has conversation-ID and dedicated-tab safeguards.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should this issue remain an investigation until paired redacted session evidence is available, or should a maintainer sponsor a controlled shared-profile concurrency reproduction?	Collect paired session evidence: Ask for both sessions’ redacted metadata, logs, runtime target/conversation IDs, and transcript headers to identify the divergent ownership path.

Why: The report is credible and high impact, but the proposed safeguards already exist in the reported release, so the unobserved bypass path cannot be repaired confidently from one archived result alone.

Next step
A concrete bypass path is not established; collect paired evidence or sponsor a controlled reproduction before changing the already-present guard.

Review details

Best possible solution:

Trace the two affected sessions’ redacted runtime metadata, logs, and transcript headers through target ID, URL, and conversation ID, then fail the run at the first unproven ownership transition and add a deterministic concurrent-profile regression test.

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

No. The reporter observed the race once but provided no deterministic paired-run trace, and current source already has conversation-ID and dedicated-tab safeguards.

Is this the best way to solve the issue?

Unclear. Conversation-ID binding is already implemented; identifying the precise ownership transition from paired evidence is the narrowest path to a durable fix.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The expected conversation ID is derived from mutable current URL state; paired metadata is needed to determine whether an unexpected navigation or reattach path replaced that identity before capture.

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

Label changes

Label justifications:

• P1: A completed session can silently deliver another run’s answer to automated callers, corrupting an active browser workflow.
• impact:session-state: The report concerns a response and transcript being associated with the wrong Oracle session.

Evidence reviewed

What I checked:

• Current capture guard: Assistant snapshots return no answer when the current page has a different stable ChatGPT conversation ID than the run’s expected ID. (src/browser/actions/assistantResponse.ts:927, 79e483bd9dc8)
• Current tab isolation: A reused manual-login Chrome session opens an isolated target and refuses fallback to the default target, reducing cross-run tab attachment. (src/browser/index.ts:1220, 79e483bd9dc8)
• Released-version check: The v0.17.3 source contains the same expected-conversation capture check, so the reporter’s v0.17.3 observation is not disproved by the existence of that guard. (src/browser/actions/assistantResponse.ts:927, 6b17e6db0cae)
• Feature history: The conversation-capture guard dates to this browser fix; later history separately records isolated parallel tabs and tab-lease coordination. (src/browser/actions/assistantResponse.ts:913, 495bd1c44097)

Likely related people:

• Peter Steinberger: History attributes the conversation-capture guard, tab-lease coordination, and the v0.17.3 release to Peter Steinberger. (role: browser capture and shared-profile feature owner; confidence: high; commits: 495bd1c44097, 7470b8dbac0b, 6b17e6db0cae; files: src/browser/actions/assistantResponse.ts, src/browser/tabLeaseRegistry.ts, src/browser/index.ts)
• Gary Basin: History identifies Gary Basin as the author of isolated browser tabs for parallel sessions. (role: introduced parallel browser tab isolation; confidence: medium; commits: 0692dccece07; files: src/browser/chromeLifecycle.ts, src/browser/index.ts)
• DragonFSKY: Merged work on ChatGPT Work-session normalization classifies conversations by exact ID. (role: recent ChatGPT conversation-identification contributor; confidence: medium; commits: 80ebcf866fab, f7ab9d39f11f; files: src/browser/index.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.