fix(env): destroy works from wrappers that mention the target path - #105
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
|
@clawsweeper re-review This PR implements the focused repair proposed on #104. Change selectedProcess discovery now excludes:
The exclusion applies both when selecting environment-owned seed processes and when expanding their descendants. Deliberate boundaryI did not exclude the caller wrapper's entire descendant tree, and I did not weaken command-line or working-directory path ownership. A blanket wrapper-tree exclusion could hide a genuinely target-owned process launched independently by the same maintenance shell. The helper therefore excludes current-process descendants, not siblings, and the unit test proves that distinction. Evidence
No local OCM deployment or gateway restart was performed. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Codex review: needs maintainer review before merge. Reviewed August 21, 2026, 4:09 PM ET / 20:09 UTC. ClawSweeper reviewWhat this changesThe PR excludes the running OCM command, its ancestors, and its descendants from Unix environment-process discovery, and adds a wrapper-path destroy regression test. Merge readinessKeep open for normal maintainer merge review: this member-authored PR has a focused, source-consistent fix with no actionable correctness finding. Likely related people: shakkernerd (environment-destroy history) and Vincent Koc (guarded-destroy history). Priority: P2 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits together
flowchart LR
A[Shell wrapper] --> B[OCM destroy command]
B --> C[Process-table snapshot]
C --> D[Exclude active invocation tree]
D --> E[Find environment processes]
E --> F[Preview or guarded teardown]
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Merge the narrow invocation-tree exclusion while retaining the wrapper regression as the contract for guarded destroy process discovery. Do we have a high-confidence way to reproduce the issue? Yes, from source and the supplied focused regression: prior command-path matching can select a wrapper that mentions the target root, while the branch test exercises preview and guarded destroy through that wrapper. This review did not independently run the current-main failure because the base tree is unavailable locally. Is this the best way to solve the issue? Yes: excluding only the active invocation tree preserves the existing command-path and working-directory ownership rules for independent processes, making it narrower than weakening path matching globally. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning high; reviewed against 768714ae3491. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
|
The platform checks requested by the latest review are now complete:
I made no additional code change because the review identified no actionable correctness finding. The remaining merge-risk note is already covered by the checked-in wrapper regression: it proves the invocation tree is excluded while an independent sibling process remains detectable and survives destroy. The review's live-verification command did not reach the Rust test because its setup attempted a Corepack download. That setup failure does not contradict the focused local before/after reproduction or the now-green hosted platform runs. The PR body has been updated with the completed CI evidence. |
|
🦞👀 I queued a lightweight read-only assist pass. It will post a separate answer comment and will not edit the durable ClawSweeper review comment or trigger close, merge, repair, label, or branch changes. Request: The platform checks requested by the latest review are now complete: - macOS: passed - Ubuntu: passed - Windows compile: passed - Rust 1.88 minimum: passed - Format: passed I made no additional code change because the review identified no actionable correctness finding. The remaining merge-risk note is already covered by the checked-in wrapper regression: it proves the invocation tree is excluded while an independent sibling process remains detectable and survives destroy. The review's live-veri... |
|
ClawSweeper assist: The completed platform checks strengthen the existing evidence, but the PR body was updated after the latest ClawSweeper review, so a fresh correctness review is needed for the current PR state. Evidence:
Suggested next action: Request a current-state review with Source: #105 (comment) |
Closes #104
Additional instructions
MUST: Keep Allow edits from maintainers enabled for this PR so maintainers
can help update the branch when needed.
What Problem This Solves
ocm env destroycan classify its own caller wrapper as a process owned by the target environment when the wrapper command line mentions the environment root. Descendant expansion then pulls the active OCM invocation and transient inspection processes into the candidate set, so the two guarded process scans can disagree and fail with:This blocks preview and guarded destroy even when the target service is stopped and no target-owned process is running.
Why This Change Was Made
Exclude the active OCM invocation from environment ownership discovery: the current OCM process, its caller ancestry, and descendants spawned by that OCM process are ignored as candidate seeds and during descendant expansion.
The exclusion deliberately does not remove siblings or all descendants of the caller wrapper, and it does not weaken path-based ownership matching. Independent processes whose command line or working directory belongs to the target environment remain detectable and terminable. This keeps the repair scoped to the invocation tree that cannot safely be treated as destroyable target work.
User Impact
Operators can preview and perform guarded environment destruction from shell wrappers, maintenance scripts, and diagnostic flows whose command lines mention the target path. The destroy guard remains stable instead of counting its own invocation.
Genuinely target-owned processes are still discovered, while independent sibling-environment processes remain untouched.
Evidence
mainwith the exact reported inspection-state error.processCount: 0, guarded destroy succeeds, and an independent sibling process remains running.cargo test --locked invocation_processes_include_ancestors_and_current_descendants_only -- --nocapture: passed.cargo test --locked --test env_destroy_tests: 14 passed, 0 failed.cargo fmt --all -- --check: passed.git diff --check origin/main..HEAD: passed.