4.3.4: host-routed see refused on screen+element detection (no in-process fallback); SCK coordination blocks host capture while another Screen-Recording app is open

[jnikolaidis]

Summary

Two capture problems on a launchd-managed background host (macOS 26.6.2, arm64, Mac mini M4 Pro) after upgrading 4.3.0 → 4.3.4. Both make every host-routed see unusable; caller-local (--no-remote) works reliably.

Environment: Peekaboo 4.3.4 CLI (Homebrew openclaw/tap), Peekaboo.app 4.3.4 installed (Bridge host on ~/Library/Application Support/Peekaboo/bridge.sock), caller is a launchd Node process holding Screen Recording + Accessibility + Full Disk Access.

1. Bridge host refuses screen capture when element detection runs (persists in 4.3.4)

Related: #710 — same signature, whose follow-up isolated AX element detection as the trigger.

Measured with no daemon running, no app running, and no other SCK-capable app open:

invocation	result
peekaboo see --mode screen --json	FAIL INTERACTION_FAILED — "The desktop observation provider returned response evidence that did not match the requested unexpected application evidence."
peekaboo see --mode screen --no-elements --json	success
peekaboo see --capture-engine classic --mode screen --json	FAIL, same rejection
peekaboo see --no-remote --mode screen --json	success, 193 elements

So default routing dispatches to an on-demand Bridge host and is refused; only disabling element detection, or bypassing the host entirely, succeeds.

2. Behaviour change vs 4.3.0: no in-process fallback

version	state	peekaboo see --mode screen
4.3.0	no daemon running	success — in-process fallback, 189 elements
4.3.4	no daemon, no app	FAIL — routed to a host and refused

On 4.3.0 the command fell back to the caller when no host existed; on 4.3.4 it always prefers a host, so previously working plain invocations now fail. If that is intentional, a documented fallback would help.

3. SCK coordination blocks all host capture while an unrelated Screen-Recording app is open

With another app that simply holds Screen Recording running (Claude Desktop), but not capturing, host capture failed on every route with:

ScreenCaptureKit coordination cannot be proven for potential host processes: PID 16481 (generation ...)
Blockers: PID 16481, generation ..., /Applications/Claude.app/Contents/MacOS/Claude
The ownership check did not dispatch ScreenCaptureKit.

The engine docs say the lease "scans and refuses owner-unaware live processes" and that "a potential uncoordinated host is not proof of actual SCK use" — yet the check keyed on a merely running app here, making host capture impossible on an ordinary desktop. The coordination error disappeared as soon as that app quit. Suggest scoping the scan to processes with an actual SCK session/lease, or documenting that any Screen-Recording-entitled app must be closed.

Impact

Automation on a background host cannot use default see at all; callers must pass --no-remote. Host-side element detection is unavailable.

Workaround in use

PEEKABOO_NO_REMOTE=1 PEEKABOO_CAPTURE_ENGINE=classic — reliable (193 elements repeatedly), with or without a daemon/app running and with other SCK-capable apps open.

Notes

• 4.3.4 did fix the frontmost daemon-capture path from 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 #710's original report.
• Happy to run further diagnostics or test candidate builds on this host.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 12, 2026, 3:52 AM ET / 07:52 UTC.

Summary
The screen-plus-elements failure remains on main and in v4.3.4. The related report independently confirms it; the merged frontmost fix explicitly excluded this path. Claude coordination and caller-local fallback involve intentional policies, so they need separate treatment from the attribution defect.

Reproducibility: yes. from source: an unscoped screen target receives frontmost-application AX metadata that the Bridge rejects. Both reports isolate this with --no-elements and --no-remote; native execution was unavailable on this Linux reviewer.

Regression provenance
Possible regression — suspected (failure trace). No predecessor PR is attributed.

Maintainer decision needed

Question	Recommendation
Should this repair preserve the existing known-host coordination guard and explicit routing boundary, or also revise Claude Desktop classification?	Preserve safeguards and repair attribution: Fix screen-plus-AX validation alongside the related report and verify existing explicit classic recovery without changing default host ownership.

Why: The screen attribution defect is source-proven, but the requested scan and fallback changes alter deliberate ownership safeguards preserved by a prior merged repair.

Next step
Route the signed-attribution repair with #710 to steipete; ownership-policy changes need explicit review before automated implementation.

Security
Needs attention: The repair touches signed observation attribution; no authorization bypass is established, but validation must remain intact.

Review details

Best possible solution:

Represent screen pixels and application-scoped AX evidence distinctly, preserve authenticated attribution, and retain explicit same-host classic recovery with clear blocker diagnostics.

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

Yes, from source: an unscoped screen target receives frontmost-application AX metadata that the Bridge rejects. Both reports isolate this with --no-elements and --no-remote; native execution was unavailable on this Linux reviewer.

Is this the best way to solve the issue?

Partly: repairing producer-to-validator attribution is justified, but scanning only active SCK sessions would not preserve the documented process-lifetime safeguard. Explicit same-host classic recovery already exists.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Accepting screen AX metadata must retain process-generation and window attribution guarantees rather than bypass signed observation validation.
• The report does not isolate explicit host-side classic capture with elements disabled while Claude remains open; the claimed all-route coordination failure is broader than the established source defect.

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

Label changes

Label changes:

• add P1: A current-release default host observation workflow fails for a real automation user, with an independently confirmed source mechanism.
• add impact:other: The failure blocks desktop screenshots with actionable accessibility elements, outside the 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-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: A current-release default host observation workflow fails for a real automation user, with an independently confirmed source mechanism.
• impact:other: The failure blocks desktop screenshots with actionable accessibility elements, outside the specific impact categories.

Evidence reviewed

Security concerns:

• [medium] Preserve attribution when accepting screen AX evidence — Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeDesktopObservationBinding.swift:488
  Removing the unexpected-PID check without defining separate screen and AX provenance could allow mismatched application evidence to be certified; the repair needs valid and wrong-process cases.
  Confidence: 0.94

What I checked:

• Current report and independent confirmation: The supplied v4.3.4 report isolates host screen capture with elements: disabling elements or selecting caller-local execution succeeds. The human follow-up at 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 #710 independently reports the same screen-mode distinction on v4.3.0.
• Current validator rejects normal screen detection metadata: Screen target resolution supplies no application. validateApplicationEvidence rejects any element window-context PID when target.app is absent, producing the reported unexpected-application-evidence refusal. (Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeDesktopObservationBinding.swift:484, ba778dfe891f)
• Production accessibility producer supplies the rejected PID: ElementDetectionWindowResolver selects the frontmost application for an unscoped context. The normal read-only detection path returns that application's PID and process generation in resolvedContext, which is passed into the detection result. (Core/PeekabooAutomationKit/Sources/PeekabooAutomationKit/Services/UI/ElementDetectionService.swift:424, ba778dfe891f)
• Merged fix expressly leaves screen attribution unresolved: fix(see): preserve frontmost observation identity #712 merged as 7254eed. Its body and commit message explicitly leave screen-plus-AX attribution and publication ordering as separate work. (7254eed8fbd7)
• Release and main comparison: The latest published release is v4.3.4. GitHub comparison shows only changelog and appcast changes between that release and reviewed main, so no later runtime fix resolves this report. (ba778dfe891f)
• Claude is an explicit known-host match: The process classifier includes com.anthropic.claudefordesktop explicitly; it does not classify every application holding Screen Recording permission. Matching same-user live processes without valid cooperation receipts become blockers. Owner-lease tests explicitly include the Claude main executable. (Core/PeekabooAutomationKit/Sources/PeekabooAutomationKit/Services/Capture/ScreenCaptureKitProcessCapabilityRegistry.swift:331, ba778dfe891f)

Likely related people:

• Peter Steinberger: Raw commit e68a46c adds Core/PeekabooCore/Sources/PeekabooBridge/PeekabooBridgeDesktopObservationBinding.swift:488 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.

[steipete]

The screen-plus-elements attribution failure is fixed on main by #722 (4338bc31e6cd39b5293f9578515a3a3571e7894a). The Bridge now validates the AX process/window/focused-element evidence separately from the screen raster; missing generations and contradictory owners remain rejected.

Signed Bridge 1.38 before/after proof: pixels-only capture succeeded in both cases. Screen+AX failed with the reported “unexpected application evidence” message before the fix and returned 12 elements with a separate generation-bound semantic owner afterward. Both used explicit classic capture on the same task host.

ScreenCaptureKit coordination and default fallback policies are unchanged, so I am leaving this issue open for that policy portion. The rejected-capture output-file problem tracked in #710 is being handled separately.

[steipete]

Both parts are now fixed on main:

1. Screen capture with element detection: fixed by fix: separate screen capture and accessibility ownership #722 (see the earlier comment) — the Bridge validates the AX process/window/focused-element evidence separately from the screen raster.
2. Refusal while another Screen Recording app is open: fixed by fix(capture): allow concurrent third-party capture apps #734 (1e23ab826593509bf0a9330386bd67f5c4b68607). The "ScreenCaptureKit coordination" pre-flight that treated any capture-capable process (Claude Desktop, OpenClaw, etc.) as a competing host is gone; only Peekaboo's own daemon coordination remains, and real ScreenCaptureKit errors are surfaced as themselves. Proof on a Mac with Claude and OpenClaw running: all six window/screen × default/SCK/classic host-routed see captures succeed, and the eight-app capture harness passes 8/8. With the refusal removed, an in-process fallback is no longer needed for this case.

Both fixes will ship in the next release (4.3.5). Closing as fixed on main; please reopen with the JSON receipt if a host-routed see still refuses on that build.