4.3.0: all 'see' captures refused via the on-demand daemon ("response evidence did not match"); --no-remote works, and the PNG is written despite the refusal

[gabrielexito-stack]

On 4.3.0 every see capture is refused when the CLI hands the request to the on-demand daemon. The identical command with --no-remote succeeds. This is deterministic, survives killing the daemon (it respawns and fails the same way), and affects --mode frontmost, --mode screen and --app alike.

$ peekaboo --version
Peekaboo 4.3.0 (main/44eff916c, built: 2026-09-02T13:31:24-07:00)

Fails via daemon

$ peekaboo see --mode frontmost --path /tmp/fm.png
⛔ Action refused before dispatch; update the runtime before retrying
Error: The desktop observation provider returned response evidence that did not match the requested frontmost application snapshot identity.

$ peekaboo see --mode screen --path /tmp/sc.png
⛔ Action refused before dispatch; update the runtime before retrying
Error: The desktop observation provider returned response evidence that did not match the requested unexpected application evidence.

Three consecutive --mode frontmost runs produced the identical refusal. After pkill -f 'peekaboo daemon' the daemon respawns on demand and both commands fail identically, so this is not stale daemon state.

Works with --no-remote

$ peekaboo see --mode frontmost --path /tmp/fm-test.png --no-remote
🖼️  Screenshot saved to: /tmp/fm-test.png
📱 Application: ChatGPT
[win] Window: ChatGPT
🧊 Detection method: AXorcist
📊 UI elements detected: 16
⚙️  Interactable elements: 2
⏱️  Execution time: 1.92s

--mode screen --no-remote likewise succeeds. Same binary, same TCC grants (Screen Recording, Accessibility and Event Synthesizing all Granted), only the runtime host differs. --json confirms the failing path:

DEBUG: Runtime host: remote onDemand via /Users/agent/Library/Application Support/Peekaboo/daemon-8a6bfeca4f613a42.sock (build 4.3.0 (4.3.0))
VERBOSE [Capture]: Using desktop observation pipeline {target=frontmost}
VERBOSE [Operation]: Operation completed {operation=see_command, success=false, error=The desktop observation provider returned response evidence that did not match the requested frontmost application snapshot identity.}

Daemon and CLI are the same build (4.3.0), so this is not version skew.

Two secondary problems

1. The refusal still writes the PNG. Every refused run left a full screenshot on disk:

-rw-------@ 1 agent  wheel  459473 Sep  8 20:54 /tmp/fm1.png
-rw-------@ 1 agent  wheel  459651 Sep  8 20:54 /tmp/fm2.png
-rw-------@ 1 agent  wheel  459616 Sep  8 20:54 /tmp/fm3.png

A caller that checks for the output file rather than parsing stderr will consume an image the tool declined to vouch for. If the evidence check fails, the artifact should not be left behind.

2. Malformed error string. The --mode screen variant renders as "did not match the requested unexpected application evidence" — the template appears to interpolate a fallback descriptor into a slot expecting a target description. The frontmost variant reads correctly, so it looks like a missing case in the message builder rather than a distinct failure.

Also, ⛔ ... update the runtime before retrying is misleading here: the runtime is current and the same build succeeds locally. The actionable hint would be to name the daemon path.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 8, 2026, 10:00 AM ET / 14:00 UTC.

Summary
Keep open: current source supports the daemon-only failures and premature artifact publication. No merged fix was established, and the relevant Bridge validator is unchanged in v4.3.3.

Reproducibility: yes. from source: normal screen accessibility detection produces application evidence the Bridge rejects, and frontmost capture metadata conflicts with whole-identity validation. The supplied daemon/local comparison is concrete; no native reproduction was executed here.

Next step
Route to steipete for a focused repair spanning signed evidence and artifact publication; this security-sensitive boundary is unsuitable for automatic issue-to-PR intake.

Security
Needs attention: Rejected target evidence can leave a caller-visible image, so repair requires care around artifact trust and signed observation validation.

Review details

Best possible solution:

Align production observation metadata with signed validation, publish only validated artifacts, preserve intentional AX-incomplete raster recovery, and report the selected host with accurate recovery guidance.

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

Yes, from source: normal screen accessibility detection produces application evidence the Bridge rejects, and frontmost capture metadata conflicts with whole-identity validation. The supplied daemon/local comparison is concrete; no native reproduction was executed here.

Is this the best way to solve the issue?

The repair direction is clear: reconcile producers and validators while retaining process-generation and exact-window checks. Disabling attestation or deleting every raster after any observation error would violate existing safety or recovery contracts.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact app-target failure remains undiagnosed; the report supplies detailed errors only for frontmost and screen modes.
• Native after-fix validation must cover both accepted observations and wrong-process or stale-generation rejection before changing signed evidence semantics.

Codex review notes: model internal, reasoning medium; reviewed against 6cd38c0d319a.

Label changes

Label changes:

• add P1: The default daemon observation workflow is failing for a real user, blocking the UI evidence used by subsequent automation.
• add impact:other: The issue concerns rejected desktop captures and misleading screenshot artifacts, outside the more specific impact categories.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: The default daemon observation workflow is failing for a real user, blocking the UI evidence used by subsequent automation.
• impact:other: The issue concerns rejected desktop captures and misleading screenshot artifacts, outside the more specific impact categories.

Evidence reviewed

Security concerns:

• [medium] Rejected observations leave published artifacts — Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeServer+Handlers.swift:623
  The observation service writes the requested image before Bridge validation. A subsequent evidence rejection leaves a file that downstream automation may mistake for a validated result; publication must preserve existing files and distinguish intentionally retained valid rasters.
  Confidence: 0.98

What I checked:

• Concrete report and documented contract: The supplied report includes repeated 4.3.0 daemon refusals, successful identical --no-remote commands, and files remaining after refusal. Current documentation describes daemon-backed see as the default observation path and --no-remote as an explicit alternative. (docs/commands/see.md:10, 6cd38c0d319a)
• Frontmost identity and capture-mode contradictions: The validator compares the entire frontmost ApplicationIdentity at line 155 and requires frontmost capture mode. ObservationTargetResolver resolves a generation-backed frontmost application to an exact window; DesktopObservationService+Capture captures that window and replaces the target application with capture metadata. Exact-window capture metadata omits executablePath and activationPolicy supplied by ApplicationService+Discovery, so whole-struct equality can reject the same process generation. The exact-window capture also produces window mode, requiring a separate reconciliation with the requested frontmost semantics. (Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeDesktopObservationBinding.swift:155, 6cd38c0d319a)
• Screen detection conflicts with global evidence validation: Screen observations have no target application, but normal see requests enable accessibility detection. ElementDetectionWindowResolver selects the frontmost application for an unscoped context, and ElementDetectionService puts its PID into the returned window context. This validator rejects that PID as unexpected application evidence. This explains the screen refusal without requiring daemon version skew. (Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeDesktopObservationBinding.swift:484, 6cd38c0d319a)
• Output precedes Bridge validation: DesktopObservationService writes output at line 566 and publishes its reserved snapshot before returning. The Bridge handler then validates the result at lines 623–628. ObservationOutputWriter writes the requested raw path atomically at line 124; the later Bridge refusal has no corresponding rollback in this handler. The malformed requested unexpected application evidence wording comes directly from the error interpolation in PeekabooBridgeServer+MutationProof.swift. (Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeServer+Handlers.swift:621, 6cd38c0d319a)
• Existing tests miss the production evidence shapes: The frontmost binding test copies the result application directly into the snapshot, bypassing differing metadata from independent production producers. Screen fixtures omit elements. These tests verify important rejection rules but do not establish successful real producer-to-validator composition for the reported commands. (Core/PeekabooCore/Tests/PeekabooTests/PeekabooBridgeDesktopObservationBindingTests.swift:540, 6cd38c0d319a)
• Artifact preservation has an intentional exception: The documented ACCESSIBILITY_INCOMPLETE behavior preserves a valid requested raster while withholding unusable element snapshots. A repair must distinguish that supported behavior from artifacts whose target evidence fails validation, and must not indiscriminately delete existing user files. (docs/commands/see.md:169, 6cd38c0d319a)

Likely related people:

• Peter Steinberger: Raw commit e68a46c adds Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeDesktopObservationBinding.swift:155 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: e68a46c227b9; files: Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeDesktopObservationBinding.swift)

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.

[gabrielexito-stack]

Follow-up with a tighter repro. The title's "all see captures" is imprecise — I've now isolated the variable, and it is AX element detection, not the capture mode. This lines up with the review comment's ElementDetectionWindowResolver hypothesis, so posting the native evidence for it.

Same host, same 4.3.0 build, daemon respawned, run twice with identical results:

invocation	rc	error
see --mode screen --no-elements (daemon)	0	—
see --mode screen (daemon)	1	…did not match the requested unexpected application evidence
see --mode frontmost --no-elements (daemon)	1	…did not match the requested frontmost application snapshot identity
see --mode frontmost (daemon)	1	…did not match the requested frontmost application snapshot identity
see --mode screen (--no-remote)	0	—
see --mode frontmost (--no-remote)	0	—

So there are two distinct rejections behind the one report:

1. Screen mode is refused only when element detection runs. --no-elements is the single daemon invocation that succeeds. That is exactly the path the review describes: screen requests carry no target application, ElementDetectionWindowResolver selects the frontmost app for the unscoped context, its PID lands in the returned window context, and the validator rejects it as unexpected application evidence. --no-elements skips the detection, nothing injects a PID, and the capture validates. The malformed message string is emitted only on this path.

2. Frontmost is refused regardless of --no-elements. Different mechanism — the whole-ApplicationIdentity comparison, which --no-elements cannot avoid because the mode itself resolves an application target.

My original report said screen and frontmost failed "alike"; they fail for different reasons, and screen has a working carve-out. Everything else stands and re-reproduces today, including the premature write — note the failing rows above still leave a full-size PNG on disk next to rc=1, and the 1.6 MB screen artifact is written even though the evidence check rejected it.