4.3.0: name resolution still fails closed on a terminated LaunchServices record (follow-up to #677)

[gabrielexito-stack]

Follow-up to #677. That fix ("distinguishes repeated explicit EPERM on a foreign prohibited helper from genuinely uncertain metadata") resolved the root-owned-daemon case, but on 4.3.0 the same fail-closed behaviour still occurs for a terminated process that LaunchServices has not yet reaped. A dead PID falls on the "genuinely uncertain metadata" side of that split, so one stale LS record aborts the entire mutation inventory and every name-resolved command on the machine fails.

Reproduction

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

$ peekaboo app hide --app Finder --no-remote
⛔ Action refused before dispatch; refresh the target before retrying
Error: Application inventory was incomplete while resolving 'Finder'. Application PID 424 lacked process-generation identity and was omitted. Hint: Refresh the target inventory and retry with its exact PID, process generation, and window ID.

Same with the daemon path (--no-remote omitted), so this is not a runtime-host artifact.

PID 424 does not exist

$ ps -o pid,uid,stat,comm -p 424
  PID   UID STAT COMM
$ echo $?
1

$ kill -0 424
kill: kill 424 failed: no such process

It is only a residual LaunchServices ASN entry:

$ lsappinfo info -only pid,name,bundleid,LSDisplayName,StatusLabel 424
"pid"=424
"LSDisplayName"="openclaw"
"CFBundleIdentifier"="com.apple.iWork.Keynote"
"StatusLabel"=[ NULL ]

(The bundle id is stale/mismatched too — this is a dead node process whose LS record was never cleaned up.) It survives a daemon kill/respawn and persists across runs.

Impact

Every --app <name> command is refused machine-wide until the LS record clears. --pid <n> still works and is the only workaround:

$ peekaboo click --app Calculator --on B7      # refused, same error
$ peekaboo click --pid 31462 --on B7           # ✓ works

Suggested handling

processStartIdentity failing with ESRCH (or the PID otherwise not existing) means the entry is dead, not uncertain — a dead process cannot be a mutation target and cannot cause PID-reuse ambiguity against a live named target. Treating "process is gone" the same way #678 treats "explicit EPERM on a foreign prohibited helper" (drop the entry, keep the inventory complete) would close this without weakening the uniqueness guard, since a genuinely reused PID would resolve and fingerprint successfully.

[clawsweeper]

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

Summary
The reported failure remains possible on current main and v4.3.3. The earlier fix deliberately excludes only verified permission-denied helpers; terminated-process handling remains distinct, actionable work.

Reproducibility: yes. the conditional failure is source-reproducible: a listed PID whose generation lookup returns ESRCH becomes an omission and blocks name selection. Native reproduction was not run on this Linux review host.

Maintainer decision needed

Question	Recommendation
What native evidence should permit a terminated LaunchServices row to be excluded without making mutation inventory partial?	Approve a narrowly proven absence exception: Define a native absence check with race-focused coverage while retaining fail-closed handling for arbitrary failures and changing generations.

Why: The current documented and tested safety contract intentionally treats ESRCH as unavailable; changing that exclusion boundary requires agreement on process-death and PID-reuse semantics.

Next step
Resolve the native absence-exclusion safety contract before dispatching a focused repair; the defect is bounded, but its fix changes an intentional targeting guard.

Review details

Best possible solution:

Represent confirmed process absence separately from unreadable identity, excluding only proven dead records while preserving ambiguity refusal, generation revalidation, and inventory deadlines.

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

Yes, the conditional failure is source-reproducible: a listed PID whose generation lookup returns ESRCH becomes an omission and blocks name selection. Native reproduction was not run on this Linux review host.

Is this the best way to solve the issue?

Unclear whether the suggested ESRCH-only exception is sufficient; separating confirmed absence is appropriate, but its native observation and PID-reuse safeguards need definition.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reporter's separate process checks establish apparent death, but do not establish the exact native generation-read result or its timing.
• A dead-process exception needs a defined observation boundary so unreadable live processes and PID reuse cannot silently disappear from uniqueness checks.

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

Label changes

Label changes:

• add P1: A residual process record reportedly blocks ordinary name-targeted automation across unrelated applications.
• add impact:other: The impact is desktop automation refusal, outside the more specific owned 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-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P1: A residual process record reportedly blocks ordinary name-targeted automation across unrelated applications.
• impact:other: The impact is desktop automation refusal, outside the more specific owned impact categories.

Evidence reviewed

What I checked:

• Reported native failure: The supplied issue body reports Finder hide refusal on 4.3.0 through both local and daemon routes, a residual LaunchServices entry for PID 424, and separate ps/kill observations that the process no longer exists. Explicit-PID targeting reportedly succeeds. Those observations do not capture errno from Peekaboo's own generation lookup.
• Current source preserves the failure mechanism: Failed generation reads distinguish EPERM only; ESRCH becomes unavailable. Discovery appends an omission warning for unavailable identities and marks the inventory partial. (Core/PeekabooAutomationKit/Sources/PeekabooAutomationKit/Services/System/SystemIdentityResolver.swift:129, 6cd38c0d319a)
• Inventory omission blocks unrelated names: Only the repeatedly verified foreign-prohibited EPERM case skips a missing generation without warning. Any remaining warning makes the entire mutation inventory partial. (Core/PeekabooAutomationKit/Sources/PeekabooAutomationKit/Services/System/ApplicationService+Discovery.swift:66, 6cd38c0d319a)
• Existing safety and workaround contracts: Planner tests require partial inventories to refuse name selection and verify that exact PID targeting uses direct proof instead. The resolver test explicitly expects ESRCH to remain unavailable; this is not an already-implemented exception. (Core/PeekabooAutomationKit/Tests/PeekabooAutomationKitTests/SystemIdentityResolverTests.swift:24, 6cd38c0d319a)
• Documented exclusion boundary: The documented mutation-inventory contract permits only verified EPERM helper exclusions and keeps other failures, changing evidence, and disappearing readable generations fail-closed. (docs/application-resolving.md:125, 6cd38c0d319a)
• Latest release still has the relevant implementation: GitHub reports v4.3.3 as the latest release, published September 8. Its tag resolves to 46d7586; comparing both identity and discovery source files against HEAD produced no differences. (Core/PeekabooAutomationKit/Sources/PeekabooAutomationKit/Services/System/ApplicationService+Discovery.swift:66, 46d7586c7f0e)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

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]

Fixed on main by #721 (01b8b3118043117d9449e680f1e7e6dbfb4fe994). Application discovery now excludes a stale LaunchServices record only after two consecutive kernel identity reads explicitly report ESRCH. Partial reads, other errors, and generation changes remain fail-closed.

Regression proof retained the PID of a real exited/reaped process in a synthetic LaunchServices inventory: the old code produced a partial inventory, while the fix resolved the live application by both name and bundle. The signed production inventory/planner proof passed; 27 focused tests and all exact-head macOS/CodeQL checks passed. See #721 for commands and proof details.