From 7be19b20cd967fdf96ab9ca7a361b421c4b05f76 Mon Sep 17 00:00:00 2001 From: Alex Newman Date: Thu, 5 Feb 2026 20:09:52 -0500 Subject: [PATCH] MAESTRO: Close PR #847 - observer session isolation already shipped via PRs #845, #733 All changes from the comprehensive PR were merged incrementally: - PR #845 (v9.0.12): cwd isolation replacing CLAUDE_CONFIG_DIR - PR #733: EnvManager.ts with buildIsolatedEnv() for credential isolation - CLAUDE_MEM_CLAUDE_AUTH_METHOD setting already in SettingsDefaultsManager Co-Authored-By: Claude Opus 4.6 --- Auto Run Docs/PR-Triage/PR-Triage-06.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Auto Run Docs/PR-Triage/PR-Triage-06.md b/Auto Run Docs/PR-Triage/PR-Triage-06.md index 647075af..7df2e5c2 100644 --- a/Auto Run Docs/PR-Triage/PR-Triage-06.md +++ b/Auto Run Docs/PR-Triage/PR-Triage-06.md @@ -14,7 +14,8 @@ These PRs address orphaned/zombie processes. This is a recurring theme — v9.0. - [x] Review PR #879 (`fix: add daemon children cleanup to orphan reaper` by @boaz-robopet). File: `src/services/worker/ProcessRegistry.ts`. The existing orphan reaper (v9.0.8) may not catch daemon child processes. Steps: (1) `gh pr checkout 879` (2) Review — does the reaper currently miss child processes of daemon-spawned workers? (3) Single file change, low risk. If the logic is sound: `gh pr merge 879 --rebase --delete-branch` > **Result: MERGED** — Addresses a real gap in process cleanup. The existing reaper handles two cases: (1) registry-tracked processes for dead sessions, and (2) system orphans with ppid=1. Neither catches Claude SDK processes that are children of the living daemon but idle/stuck. The new `killIdleDaemonChildren()` function targets processes where ppid=daemon, CPU=0%, and running >2 minutes. Clean single-file addition (83 lines), proper etime parsing for all formats, integrated into the existing 5-minute reaper cycle. Build passes. -- [ ] Review PR #847 (`fix: comprehensive observer session isolation without breaking auth` by @bigph00t). Files: ProcessRegistry.ts, SDKAgent.ts, EnvManager.ts, paths.ts, etc. (7 files). Steps: (1) `gh pr checkout 847` (2) v9.0.12 already fixed observer isolation (using SDK `cwd` option instead of CLAUDE_CONFIG_DIR). Check if this PR provides additional isolation beyond v9.0.12. (3) If it's substantially the same as what shipped in v9.0.12, close with: `gh pr close 847 --comment "Observer session isolation was addressed in v9.0.12 using SDK cwd option. If there are remaining isolation gaps, please describe the specific scenario and reopen."` (4) If it addresses real remaining gaps, review and merge. +- [x] Review PR #847 (`fix: comprehensive observer session isolation without breaking auth` by @bigph00t). Files: ProcessRegistry.ts, SDKAgent.ts, EnvManager.ts, paths.ts, etc. (7 files). Steps: (1) `gh pr checkout 847` (2) v9.0.12 already fixed observer isolation (using SDK `cwd` option instead of CLAUDE_CONFIG_DIR). Check if this PR provides additional isolation beyond v9.0.12. (3) If it's substantially the same as what shipped in v9.0.12, close with: `gh pr close 847 --comment "Observer session isolation was addressed in v9.0.12 using SDK cwd option. If there are remaining isolation gaps, please describe the specific scenario and reopen."` (4) If it addresses real remaining gaps, review and merge. + > **Result: CLOSED** — All changes from this comprehensive PR were already shipped incrementally via three merged PRs: PR #845 (v9.0.12, `cwd` isolation replacing `CLAUDE_CONFIG_DIR`), PR #733 (`EnvManager.ts` with `buildIsolatedEnv()` for credential isolation), and the `CLAUDE_MEM_CLAUDE_AUTH_METHOD` setting. Current main branch `SDKAgent.ts` already uses both `cwd: OBSERVER_SESSIONS_DIR` and `env: isolatedEnv`. Closed with detailed explanation. - [ ] Review PR #738 (`fix(worker): add subprocess lifecycle cleanup for zombie haiku agents` by @fedosov). Files: 8 source files + tests. Adds QueryWrapper/QueryWrapperManager for subprocess lifecycle management. Steps: (1) `gh pr checkout 738` (2) Check overlap with ProcessRegistry (v9.0.8) — does this add a parallel tracking system? That would be redundant. (3) If it extends ProcessRegistry, good. If it introduces a separate system, close and suggest integrating with ProcessRegistry. (4) Run `npm run build` and tests.