Skip to content

fix(daemon): share one user daemon across configurations - #346

Merged
steipete merged 4 commits into
mainfrom
steipete/single-user-daemon-20260904
Sep 5, 2026
Merged

fix(daemon): share one user daemon across configurations#346
steipete merged 4 commits into
mainfrom
steipete/single-user-daemon-20260904

Conversation

@steipete

@steipete steipete commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator

Summary

Replace config-selected keep-alive daemon processes with one OS-user broker. Configuration files become immutable client views, while equivalent stdio definitions and aliases share retained connections. Caller directory and inherited shell nesting no longer create accidental connection identities; explicit launch settings remain meaningful.

Existing Chrome has a separately reserved connection owner. Canonical global configuration controls its launch and relay policy, and conflicting temporary configs cannot start another attachment, steal the owner, or weaken required relay routing. Unrelated isolated-browser definitions do not poison the supported owner. Ordinary and generated CLIs use the same default client identity and connection.

The broker enforces view-local tool permissions and connection-scoped OAuth context. Local IPC authenticates both peers before sending resolved configuration. Timeouts are not replayed, reconnects wait for verified retirement, and idle retirement cannot interrupt queued, active, or uncertain work. HTTP aliases deliberately retain separate credential ownership. The related normalization in PR #345 is incorporated rather than duplicated.

Review follow-ups

The actionable findings in the current review are addressed:

  • Explicit migration accepts only ordinary current-user-owned legacy 0755 directories and upgrades them to 0700 with no-follow descriptor checks and pathname revalidation. Inspection remains read-only. Unsafe owners, symlinks, writable modes, and replacement races fail closed. Empty/stopped legacy installations can migrate and start normally.
  • View epochs retain every captured operation through registration and authenticated RPC setup. Replaced handles are released only after those operations settle; old failures cannot clear newer epochs.
  • Description discovery uses view-scoped metadata from the retained broker connection. An exclusive-server fixture proves list, automatic description, generation, help, and repeated discovery do not spawn a second server. Pooled raw connections and interactive-session bypasses fail explicitly.
  • Broker and host idle scheduling use bounded native timer slices while preserving full elapsed deadlines, including 30-day settings. Blocked expiry checks do not spin.
  • Chrome authority is rechecked at dequeue and immediately before SDK dispatch, after connection awaits. Authenticated relay fixtures queue a request, rotate or remove the key, and prove rejection before the queued effect counter increments. Already-executing operations are not claimed to be retroactively revocable.

Verification

Fresh CI run 33935378655 passed all Linux, macOS, and Windows jobs on review-fix head cbc0832c0628095a6f88f65465e61a7b8ac0431d.

Local pnpm check, pnpm build, and pnpm test pass on the combined fixes: 1,861 passed tests and 26 existing skips. The prior CI run 33927720741 passed Linux, macOS, and Windows on d8c37ce2accbdc8bbf71b94a21bb5b6873990e19 and is historical evidence only; the fresh run above verifies these follow-ups.

Independent source-blind CLI probes verify concurrent cold starts across config files and aliases, different caller directories, ordinary/generated reuse in both startup orders, actual child UUIDs and counters, filters, client-exit behavior, in-flight config replacement, idle protection, no replay, and generation-scoped recovery. Additional fixtures cover migration, same-client view replacement before RPC admission, exclusive metadata discovery, long timer boundaries, queued credential revocation, and post-connect dispatch checks.

Windows CI initially exposed process-observation and cleanup failures. Bounded targeted queries, validated completion data, unknown-identity refusal, reduced redundant ACL work, and correct cleanup ordering addressed them. The aggregate CLI workflow was separated into focused contracts retaining the same broker and real invocations. No runtime or CI timeout budgets or existing platform coverage were increased. Transient local SSE/liveness failures passed on unchanged focused/full reruns and are not claimed as separately fixed.

Real-Chrome smoke and remaining limit

On the earlier d8c37ce2 build, a real macOS handover retired four verified legacy daemons. An explicitly approved temporary canonical direct policy was used. After one successful foreground Chrome approval, fresh CLI processes listed pages, opened a disposable synthetic tab, and selected it. The daemon generation and single connection ID/generation remained unchanged between attachment and cleanup. The original relay-required configuration was restored byte-for-byte and the test owner was stopped.

The evaluation request was rejected because the verifier omitted the current Chrome tool's required pageId. This PR does not claim completed live evaluation, live parallel cross-config browser checks, or a new physical-browser revocation test. Those contracts have fixture coverage where stated. The basic real-browser integration, legacy retirement, and explicitly accepted live-proof limitation are recorded for landing. No further Chrome attachment attempts are authorized or included in this change.

Compatibility and rollout

Protocol v3 requires coordinated migration from old per-config hosts. Upgrade invoking clients, drain old work, inspect mcporter daemon migrate, then use the documented verified-stop and permissions-upgrade procedure. There is no silent fallback to old daemons or transfer of CDP sessions.

One retained connection is a shared MCP session, not per-agent selected-page isolation. Individual calls serialize; multi-call select-then-act workflows still need coordination. Unsupported/direct Chrome definitions and raw programmatic Chrome connections fail explicitly rather than bypass ownership. Broker-owned metadata is available without exposing an SDK context across IPC. A crash, deliberate restart, or migration can still require fresh browser approval.

No version bump, changelog edit, publication, or release is included. These behavior and compatibility notes are context for the eventual release.

Per-config hosts and accidental launch identities could create duplicate
retained connections and competing Chrome attachments. Treat resolved
configurations as immutable views of one OS-user broker, and reserve a
canonical Chrome owner whose launch and relay policy comes from the global
configuration. Ordinary and generated clients reuse the same connection.

Enforce view-local permissions and connection-scoped OAuth ownership while
preserving HTTP credential isolation. Never replay uncertain calls; require
verified retirement before reconnecting, and protect active or uncertain
work from idle shutdown.

Protocol v3 requires coordinated cutover from per-config daemons: drain old
work and use the documented migration and verified-stop procedure. Retained
connections remain shared MCP sessions; multi-call select-then-act workflows
still require caller coordination.

Local check, build, and tests pass with 1,790 tests and 26 existing skips.
Source-blind synthetic probes cover reuse, lifetime, filters, idle protection,
and recovery. Cross-platform CI and real-Chrome proof remain landing gates.
@clawsweeper

clawsweeper Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

🦞👀
ClawSweeper picked this up.

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

ClawSweeper review in progress

ClawSweeper is reviewing this revision. This supersedes any previous blocked status.

View the workflow run.

Comment thread tests/singleton-broker.integration.test.ts Fixed
`const net=require('node:net'),fs=require('node:fs'),{spawn}=require('node:child_process');
const owned=spawn(process.execPath,['-e','setInterval(()=>{},1000)'],{stdio:'ignore'});
const server=net.createServer(s=>s.on('data',chunk=>{const r=JSON.parse(chunk);s.end(JSON.stringify({id:r.id,ok:true,result:r.method==='status'?{pid:process.pid,socketPath:${JSON.stringify(socket)},protocolVersion:1,servers:[]}:true}));if(r.method==='stop'){server.close();setTimeout(()=>owned.kill(),250);}}));
server.listen(${JSON.stringify(socket)},()=>fs.writeFileSync(${JSON.stringify(metadata)},JSON.stringify({pid:process.pid,socketPath:${JSON.stringify(socket)}}),{mode:384}));`,
`const net=require('node:net'),fs=require('node:fs'),{spawn}=require('node:child_process');
const owned=spawn(process.execPath,['-e','setInterval(()=>{},1000)'],{stdio:'ignore'});
const server=net.createServer(s=>s.on('data',chunk=>{const r=JSON.parse(chunk);s.end(JSON.stringify({id:r.id,ok:true,result:r.method==='status'?{pid:process.pid,socketPath:${JSON.stringify(socket)},protocolVersion:1,servers:[]}:true}));if(r.method==='stop'){server.close();setTimeout(()=>owned.kill(),250);}}));
server.listen(${JSON.stringify(socket)},()=>fs.writeFileSync(${JSON.stringify(metadata)},JSON.stringify({pid:process.pid,socketPath:${JSON.stringify(socket)}}),{mode:384}));`,
Target and batch Windows owner/start identity observations. Validate the UTF-8 completion envelope and fail closed when process identity is unknown.

Cache Windows directory verification by filesystem identity and share in-flight host shutdown. Settle fixture requests and owned children before cleanup.

Preserve existing timeouts, CI budgets, and platform coverage.
@clawsweeper clawsweeper Bot added P2 Normal priority bug or improvement with limited blast radius. merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. merge-risk: 🚨 security-boundary 🚨 Merging this PR could weaken sandboxing, authorization, credentials, or sensitive data. merge-risk: 🚨 session-state 🚨 Merging this PR could lose, corrupt, stale, or mis-associate session or agent state. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. labels Sep 4, 2026
@clawsweeper

clawsweeper Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed September 4, 2026, 7:14 PM ET / 23:14 UTC.

ClawSweeper review

What this changes

Replace configuration-specific background processes with one authenticated user daemon that shares compatible MCP connections, preserves configuration-local tool filters, and reserves a canonical Chrome connection.

Regression provenance

Possible regression — suspected (reviewed change). No predecessor PR is attributed.

Merge readiness

Blocked before merge - 10 items remain

Keep open: the singleton behavior is distinct from current main and remains useful. The prior view-release finding is unresolved, and this review identifies three additional source-backed defects. Browser-authority proof also remains incomplete.

Priority: P2
Reviewed head: d8c37ce2accbdc8bbf71b94a21bb5b6873990e19

Review scores

Measure Result What it means
Overall readiness 🦪 silver shellfish (2/6) The implementation has substantial useful coverage, but four actionable defects and incomplete authority proof prevent merge readiness.
Proof confidence 🦪 silver shellfish (2/6) Needs stronger real behavior proof before merge: Authority-chain proof required: the broker retains canonical Chrome authority across client views and queued calls, but controlled real-Chrome handover is explicitly pending. The source-blind CLI probes and synthetic relay coverage are useful; they do not establish final browser rejection for a conflicting owner or credentials revoked after admission. This assessment applies to that authority surface, not unrelated proof exempted by collaborator status. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality 🦐 gold shrimp (3/6) Security review found an item that needs attention.

Verification

Check Result Evidence
Real behavior Needs proof Needs stronger real behavior proof before merge: Authority-chain proof required: the broker retains canonical Chrome authority across client views and queued calls, but controlled real-Chrome handover is explicitly pending. The source-blind CLI probes and synthetic relay coverage are useful; they do not establish final browser rejection for a conflicting owner or credentials revoked after admission. This assessment applies to that authority surface, not unrelated proof exempted by collaborator status. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed 13 items Pinned introduction and merge identity: The checkout is the original PR head. Its raw parent is the previous reviewed head. The verified test merge has the pinned main and PR head as its two parents, and its tree matches the head tree; the reported changes therefore survive the actual merge.
Repository policy: Read the complete root AGENTS.md and VISION.md. No nested AGENTS.md or matching maintainer-notes directory was found. Applied the preference for focused regression coverage and verifiable compatibility fixes without executing target code.
Current main does not provide the singleton: Main still derives the daemon locator from the configuration path. The merged related change, #345, explicitly preserves configuration-specific isolation and excludes global pooling, so it does not supersede this work.
Findings 4 actionable findings [P1] Migrate legacy directory permissions before enforcing owner-only access
[P2] Defer releasing a replaced view until its captured calls finish
[P2] Keep description discovery on the retained daemon connection
Security Needs attention Queued Chrome authority outlives its admission check: Credential identity is checked before the request joins the serial queue. The rotation fixture submits only after changing the credential, so it does not establish rejection when revocation occurs while an already-admitted call waits. Demonstrate rejection before final browser I/O; the current evidence does not establish an exploitable bypass.

How this fits together

MCPorter's daemon keeps MCP servers connected between CLI calls. Ordinary and generated clients submit resolved configurations to the broker, which authorizes each request and routes it to a retained server connection.

flowchart TD
  A[CLI and generated clients] --> B[Authenticated local connection]
  B --> C[Immutable configuration view]
  C --> D[Tool permission checks]
  D --> E[Connection identity and Chrome ownership]
  E --> F[Serialized retained MCP connection]
  F --> G[MCP server or Chrome relay]
  G --> A
Loading

Before merge

  • Add real behavior proof - Needs stronger real behavior proof before merge: Authority-chain proof required: the broker retains canonical Chrome authority across client views and queued calls, but controlled real-Chrome handover is explicitly pending. The source-blind CLI probes and synthetic relay coverage are useful; they do not establish final browser rejection for a conflicting owner or credentials revoked after admission. This assessment applies to that authority surface, not unrelated proof exempted by collaborator status. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
  • Migrate legacy directory permissions before enforcing owner-only access (P1) - The released host creates the daemon directory with ordinary recursive mkdir, so a POSIX installation using umask 022 has a 0755 directory. This mkdir does not change existing permissions, and the following guard rejects it even after legacy hosts are drained. The documented migration never repairs that mode, leaving upgraded daemon operations unusable. Provide an ownership-verified permission migration or explicit supported repair before creating the authentication key, without weakening the guard. This is a late discovery on code unchanged since the previous review.
  • Defer releasing a replaced view until its captured calls finish (P2) - The prior finding remains unresolved. An invocation can capture the old handle and still be waiting to establish its authenticated RPC when setDefinitions schedules releaseView. If release reaches the broker first, the broker deletes the handle and rejects that captured call with view_expired. The current regression changes client A while client B is already executing, so it misses this same-client race. Track operations using each handle and release it only after they settle.
  • Keep description discovery on the retained daemon connection (P2) - For a generic keep-alive stdio definition without a description, listTools now opens the retained daemon connection, but deriveDefinitionDescription subsequently calls runtime.connect. The wrapper delegates connect to the separate base runtime, spawning a second server while the retained one is still alive. This defeats shared discovery and can conflict with exclusive server resources. Obtain metadata from the broker-owned connection or avoid the second connection. This is a late discovery on code unchanged since the previous review.
  • Bound idle timer slices without shortening the configured deadline (P2) - The schema accepts idleTimeoutMs values above 2,147,483,647, such as a 30-day timeout. Passing that value directly to setTimeout overflows to a near-immediate timer, so a retained generic server is retired immediately after a call instead of after the configured idle period. The new host idle timer has the same overflow input and can repeatedly reschedule at that cadence. Use bounded timer slices with elapsed-deadline checks in both paths. This is a late discovery on code unchanged since the previous review.
  • Resolve security concern: Queued Chrome authority outlives its admission check - Credential identity is checked before the request joins the serial queue. The rotation fixture submits only after changing the credential, so it does not establish rejection when revocation occurs while an already-admitted call waits. Demonstrate rejection before final browser I/O; the current evidence does not establish an exploitable bypass.
  • Resolve merge risk (P2) - Protocol v3 intentionally stops compatibility with per-config hosts, noncanonical Chrome configurations, and the previous prefer-to-direct fallback; existing clients and generated bundles need a demonstrated coordinated upgrade path.
  • Resolve merge risk (P1) - Shared connections also share MCP session and selected-page state; serializing individual calls does not isolate multi-call select-then-act workflows between clients.
  • Resolve merge risk (P1) - Credential rotation after a Chrome request passes admission but before queued execution has not been shown to prevent the final browser side effect.
  • Complete next step (P2) - Repair the four findings and provide fresh-install, released-version upgrade, and final-effect Chrome-authority evidence before marking the draft ready. Redact credentials, private endpoints, IP addresses, and other private information from posted diagnostics.

Findings

  • [P1] Migrate legacy directory permissions before enforcing owner-only access — src/daemon/paths.ts:43-46
  • [P2] Defer releasing a replaced view until its captured calls finish — src/daemon/client.ts:125-126
  • [P2] Keep description discovery on the retained daemon connection — src/cli/generate/definition.ts:137-140
  • [medium] Queued Chrome authority outlives its admission check — src/daemon/broker.ts:145
Agent review details

Security

Needs attention: No dependency or workflow execution changes were introduced, but retained Chrome authority needs queued-revocation proof before merge.

Review metrics

Metric Value Why it matters
Production and test delta Production +1,876/-1,451 (net +425); tests +1,689/-3,411 (net -1,722) Production growth is justified by the stated broker architecture, while extensive replacement of old tests makes preserved contract coverage important.
Changed surface 39 production files, 35 test files, 3 documentation files The migration spans runtime, authentication context, daemon ownership, and generated clients rather than a locator-only fix.

Merge-risk options

Maintainer options:

  1. Complete the existing cutover contract (recommended)
    Repair the identified defects and demonstrate released-client migration plus allowed, conflicting, and revoked Chrome-owner behavior before landing.
  2. Pause the ownership cutover
    Keep the draft unmerged if controlled browser handover and upgrade evidence cannot yet establish safe shared ownership.

Technical review

Best possible solution:

Retain the single-owner design with safe legacy-directory migration, operation-scoped view lifetimes, broker-owned discovery metadata, bounded idle scheduling, and demonstrated Chrome authorization through final I/O.

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

Yes, source establishes focused regression cases for a 0755 released daemon directory, same-client view replacement before RPC admission, description discovery without configured metadata, and idle delays above the native timer limit. These cases were not executed during this read-only review.

Is this the best way to solve the issue?

Not yet: the shared broker addresses a problem that main still leaves open, but the patch needs the identified lifecycle, migration, discovery, and timer repairs plus final-effect authority evidence.

Full review comments:

  • [P1] Migrate legacy directory permissions before enforcing owner-only access — src/daemon/paths.ts:43-46
    The released host creates the daemon directory with ordinary recursive mkdir, so a POSIX installation using umask 022 has a 0755 directory. This mkdir does not change existing permissions, and the following guard rejects it even after legacy hosts are drained. The documented migration never repairs that mode, leaving upgraded daemon operations unusable. Provide an ownership-verified permission migration or explicit supported repair before creating the authentication key, without weakening the guard. This is a late discovery on code unchanged since the previous review.
    Confidence: 0.98
    Late finding: first raised on code an earlier review cycle already covered.
  • [P2] Defer releasing a replaced view until its captured calls finish — src/daemon/client.ts:125-126
    The prior finding remains unresolved. An invocation can capture the old handle and still be waiting to establish its authenticated RPC when setDefinitions schedules releaseView. If release reaches the broker first, the broker deletes the handle and rejects that captured call with view_expired. The current regression changes client A while client B is already executing, so it misses this same-client race. Track operations using each handle and release it only after they settle.
    Confidence: 0.97
  • [P2] Keep description discovery on the retained daemon connection — src/cli/generate/definition.ts:137-140
    For a generic keep-alive stdio definition without a description, listTools now opens the retained daemon connection, but deriveDefinitionDescription subsequently calls runtime.connect. The wrapper delegates connect to the separate base runtime, spawning a second server while the retained one is still alive. This defeats shared discovery and can conflict with exclusive server resources. Obtain metadata from the broker-owned connection or avoid the second connection. This is a late discovery on code unchanged since the previous review.
    Confidence: 0.97
    Late finding: first raised on code an earlier review cycle already covered.
  • [P2] Bound idle timer slices without shortening the configured deadline — src/daemon/broker.ts:378
    The schema accepts idleTimeoutMs values above 2,147,483,647, such as a 30-day timeout. Passing that value directly to setTimeout overflows to a near-immediate timer, so a retained generic server is retired immediately after a call instead of after the configured idle period. The new host idle timer has the same overflow input and can repeatedly reschedule at that cadence. Use bounded timer slices with elapsed-deadline checks in both paths. This is a late discovery on code unchanged since the previous review.
    Confidence: 0.98
    Late finding: first raised on code an earlier review cycle already covered.

Overall correctness: patch is incorrect
Overall confidence: 0.95

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

  • add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
  • remove rating: 🧂 unranked krab: Current PR rating is rating: 🦪 silver shellfish, so this older rating label is no longer current.

Label justifications:

  • P2: This is a substantial daemon reliability improvement, without evidence of an urgent shipped outage requiring higher item priority.
  • merge-risk: 🚨 compatibility: The protocol and canonical-owner cutover can stop existing configurations, and released daemon-directory permissions currently block upgrades.
  • merge-risk: 🚨 session-state: Previously separate configurations now share retained MCP session state, including Chrome page selection across multi-call workflows.
  • merge-risk: 🚨 security-boundary: Retained Chrome authority crosses client views, and queued credential revocation remains unproven at final browser I/O.
  • rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Authority-chain proof required: the broker retains canonical Chrome authority across client views and queued calls, but controlled real-Chrome handover is explicitly pending. The source-blind CLI probes and synthetic relay coverage are useful; they do not establish final browser rejection for a conflicting owner or credentials revoked after admission. This assessment applies to that authority surface, not unrelated proof exempted by collaborator status. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

Security concerns:

  • [medium] Queued Chrome authority outlives its admission check — src/daemon/broker.ts:145
    Credential identity is checked before the request joins the serial queue. The rotation fixture submits only after changing the credential, so it does not establish rejection when revocation occurs while an already-admitted call waits. Demonstrate rejection before final browser I/O; the current evidence does not establish an exploitable bypass.
    Confidence: 0.93

What I checked:

  • Pinned introduction and merge identity: The checkout is the original PR head. Its raw parent is the previous reviewed head. The verified test merge has the pinned main and PR head as its two parents, and its tree matches the head tree; the reported changes therefore survive the actual merge. (d8c37ce2accb)
  • Repository policy: Read the complete root AGENTS.md and VISION.md. No nested AGENTS.md or matching maintainer-notes directory was found. Applied the preference for focused regression coverage and verifiable compatibility fixes without executing target code. (AGENTS.md:1, d8c37ce2accb)
  • Current main does not provide the singleton: Main still derives the daemon locator from the configuration path. The merged related change, fix(relay): normalize effective daemon identity #345, explicitly preserves configuration-specific isolation and excludes global pooling, so it does not supersede this work. (src/daemon/client.ts:68, add13af3f0db)
  • Released upgrade starting point: The v0.13.8 host creates its daemon directory without an explicit mode, while released paths remain configuration-specific. With umask 022, that existing directory is 0755 rather than the new required 0700. (src/daemon/host.ts:112, 98e739a253fc)
  • Upgrade permission rejection: The new directory guard rejects existing group/world-readable directories. Recursive mkdir does not change an existing directory's permissions, and the migration path contains no corresponding POSIX permission upgrade. (src/daemon/paths.ts:43, d8c37ce2accb)
  • Prior replacement race remains: setDefinitions immediately schedules release of the previous handle, while invoke can still be preparing an RPC using it. Broker release deletes that handle. The replacement test changes one client's definitions while a different client's request runs, which does not exercise the reported same-client admission race. (src/daemon/client.ts:126, d8c37ce2accb)

Likely related people:

  • steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
  • Vincent Koc: 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.

  • Fix operation-scoped view release, secondary metadata connections, and oversized idle timers with focused regressions.
  • Demonstrate both fresh setup and upgrade from v0.13.8, including existing directory permissions and generated clients.
  • Add redacted final-effect evidence for allowed and conflicting Chrome owners and revocation while queued; terminal traces or recordings with diagnostics are suitable. Update the PR body for automatic re-review, or ask a maintainer to comment @clawsweeper re-review.

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 (1 earlier review cycle)
  • reviewed 2026-09-04T22:36:22.485Z sha 4d67728 :: needs real behavior proof before merge. :: [P2] Defer releasing a replaced view until its captured calls finish

Split the aggregate CLI workflow into seven named contracts that retain one shared fixture and broker throughout. Preserve every behavior assertion and fresh CLI invocation, with shared state valid for shuffled and selected cases and settled in-flight cleanup.

Remove the 25-second aggregate wrapper without increasing timeouts: keep the original 15-second subprocess timeout and existing global test and hook defaults. No runtime or CI budget changes.
Comment on lines +27 to +31
const operation = run(
process.platform === 'win32' ? process.execPath : '/bin/sh',
process.platform === 'win32' ? argv : ['-c', 'exec "$@"', 'fixture-launcher', process.execPath, ...argv],
{ env: launchEnv, cwd: callerCwd, timeout: 15000 }
);
@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. labels Sep 4, 2026
Repair legacy permissions only during explicit confirmed migration: accept
ordinary current-user-owned 0755 directories, upgrade through no-follow
owner-checked descriptors to 0700, and revalidate pathname identity.
Inspection stays read-only; unsafe modes, owners and replacements fail closed.

Retain captured client view epochs through registration, RPC setup and
settlement. Read description metadata through the retained broker connection
and reject pooled raw-connect or interactive-session bypasses. Slice broker
and host idle timers within native bounds while preserving full deadlines.
Revalidate queued Chrome authority before recovery and after connection
awaits immediately before SDK dispatch; already-running operations are not
retroactively revoked and this is not atomic network revocation.

Validation: scoped-clean static review; pnpm check, build and full test pass
with 1,861 passed and 26 existing skips. The initial liveness timing failure
passed on unchanged focused/full reruns and is not claimed separately fixed.
Synthetic CLI probes cover owner-checked 0755 migration, one-child metadata
discovery and short-window retention of a 30-day idle setting. Fake clocks
cover eventual expiry; actual MCP fixture counters cover same-client view
lifetime and queued/final-dispatch revocation.

No new Chrome attempts were made. Earlier live list/open/select proof applies
to d8c37ce; live evaluation and parallel browser checks remain incomplete.
The accepted partial-live disclosure remains in the PR. Fresh cross-platform
CI is required for this commit before the parent decides whether to land.
@steipete
steipete marked this pull request as ready for review September 5, 2026 01:21
@steipete
steipete merged commit 95edea1 into main Sep 5, 2026
10 of 11 checks passed

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cbc0832c06

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread src/daemon/client.ts
Comment on lines +184 to +187
return this.sendRequest<{ view: string; generation: string }>('registerView', {
definitions: effective,
clientInfo: epoch.clientInfo,
});

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Release every registered fast-path view

Each operation now registers a persistent view here, but both daemon fast-call paths in src/cli.ts create a fresh DaemonClient and return without calling release() (including failure paths). Consequently, repeated Chrome/Playwright/mobile invocations leave one abandoned view per process; 1,024 calls within the 15-minute expiry window exhaust the broker's view limit and make subsequent registrations fail with view_limit. Ensure these fast paths release the client in a finally block.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. merge-risk: 🚨 security-boundary 🚨 Merging this PR could weaken sandboxing, authorization, credentials, or sensitive data. merge-risk: 🚨 session-state 🚨 Merging this PR could lose, corrupt, stale, or mis-associate session or agent state. P2 Normal priority bug or improvement with limited blast radius. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants