fix(disk-hygiene): do not re-close fd in _discard_stream null_fd repair

[kyle-sexton]

No linked issue

Summary

Fix _discard_stream so it does not close null_fd when that fd number is the stream being repaired — the #1526 self-undo when fd 2 was closed outright.

Fix

• Guard os.close(null_fd) with if null_fd != target_fd after dup2.
• Add GuardTests.test_discard_stream_keeps_closed_stderr_fd_open that closes fd 2 and verifies _discard_stream leaves it open.
• Refresh the subprocess regression test docstring to note the repair is now fixed.

Verification

cd plugins/disk-hygiene/skills/clean/scripts
python3 -m unittest test_hygiene.GuardTests.test_discard_stream_keeps_closed_stderr_fd_open \
  test_hygiene.GuardTests.test_stderr_fd_closed_outright_still_denies_at_exit_2_in_a_real_process -v

Both tests pass.

Related

Refs #2088
Refs #1526

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

Claude finished @kyle-sexton's task in 2m 26s —— View job

---

Security Review

• Gather context (diff, changed files)
• Review destructive_guard.py changes
• Review test_hygiene.py changes
• Review plugin.json / CHANGELOG.md changes
• Post final findings

Reviewed the diff against origin/main (files: destructive_guard.py, test_hygiene.py, plugin.json, CHANGELOG.md). This PR touches _discard_stream, a small piece of a fail-closed security guard (destructive_guard.py decides whether to allow/deny destructive commands), so I focused on whether the fd-repair logic change could reopen the original exit-code-120 bypass (#1526) or introduce a new one.

No exploitable security vulnerability found. The core fix is correct: guarding os.close(null_fd) with if null_fd != target_fd is exactly the right condition to stop re-closing fd 2 after dup2(fd, fd)'s documented no-op, and this is the fd number the real #1526 scenario (stream.fileno() returning 2 after fd 2 was closed outright) actually hits — so the deny-path fail-closed guarantee this function exists for is preserved.

One low-severity, non-exploitable logic note found via data-flow reasoning (not something static analysis would catch):

[SUGGESTION / low confidence-of-impact, high confidence-in-mechanism] Possible UnboundLocalError masks the leak-prevention in the finally when fileno() itself raises
destructive_guard.py#L1147-L1154

null_fd = os.open(os.devnull, os.O_WRONLY)
try:
    target_fd = stream.fileno()
    os.dup2(null_fd, target_fd)
finally:
    if null_fd != target_fd:
        os.close(null_fd)

The function's own docstring calls out that fileno() can raise ("fileno itself raises for a stream with no fd"). If it does, target_fd is never bound, and the finally block's null_fd != target_fd reference raises UnboundLocalError before os.close(null_fd) runs. That new exception replaces whatever fileno() raised and is swallowed by the outer contextlib.suppress(BaseException), so null_fd is silently leaked in that branch — the old code always closed null_fd in finally regardless of what stream.fileno() did, since null_fd was the only variable it referenced there.

I don't believe this reopens #1526: both call sites (main's tail and _write_diagnostic) sit immediately before os._exit, so the OS reclaims the leaked fd on process exit either way, and the scenario that actually causes the exit-120 bypass (a real, open sys.stderr wrapping a closed fd 2) is a case where fileno() succeeds, not one where it raises. So this is a correctness nit adjacent to the security-critical code, not a bypass — flagging for completeness rather than as a blocking issue. A one-line target_fd = None initializer before the try would close the gap if it's worth hardening:
Fix this →

No issues found with plugin.json (version bump only) or CHANGELOG.md (docs only). Test file changes are test-only and out of scope for this security lane. Supply-chain / trigger / permissions concerns are out of scope here per the review lane split (zizmor's advisory covers those statically) and none of the changed files are workflow files anyway.

[claude]

Claude finished @kyle-sexton's task in 3m 22s —— View job

---

Code review complete

• Gather context (CLAUDE.md, REVIEW.md, diff)
• Understand the request
• Review changed files for correctness, error handling, test coverage, maintainability
• Post findings as inline comments
• Post summary comment

This repo has a claude-security-review.yml workflow, so this review (code-review lane per REVIEW.md) excludes security findings — none of the changes below have security impact anyway.

Summary

The core fix is correct and well-targeted: _discard_stream now skips os.close(null_fd) when os.open(os.devnull) happened to return the same fd number as the stream being repaired, which was the #1526 self-undo (dup2(fd, fd) no-op followed by an unconditional close). The new test_discard_stream_keeps_closed_stderr_fd_open test directly exercises that scenario and the updated docstring on the subprocess regression test accurately reflects the current state (the #1526 exit-120 trigger is closed structurally by the os._exit tail from #1524, independent of this fix). CHANGELOG.md and plugin.json version bump are consistent and match repo conventions.

One correctness regression (posted as an inline comment on destructive_guard.py): moving target_fd = stream.fileno() inside the try that owns null_fd means a fileno() failure now leaks null_fd instead of closing it — finally: if null_fd != target_fd: raises UnboundLocalError (swallowed by the outer contextlib.suppress) before os.close(null_fd) runs. This is exactly the "fileno raises for a stream with no fd" case the function's own docstring documents, and it's already silently exercised by test_watchdog_fire_hard_exits_2_when_the_diagnostic_write_fails via _ClosedPipeStderr (an io.StringIO subclass). Suggested fix: resolve target_fd before opening null_fd — see the inline comment for the exact diff and a fd-leak-check test suggestion.

I verified the UnboundLocalError reasoning by static analysis of Python's try/finally variable-binding semantics and by tracing the existing test suite's use of _ClosedPipeStderr; I was not able to execute the test suite in this sandbox (command execution required approval that wasn't available), so I did not independently run the tests. The PR description's own python3 -m unittest ... verification is author-claimed and unverified by me.

[github-actions]

Claude has reviewed this PR 1 time. The lane skips further automatic reviews after 5; deleting this comment resets the count.

[github-actions]

Warning

Automated review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31554418145
• Failure class: other
• Last SDK result: (no execution file was produced)

Re-run the job to retry the review. A new push re-triggers this lane only if the caller's pull_request triggers include synchronize (the canonical caller omits it).
An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator (auth).

[github-actions]

Warning

Automated security review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31554418183
• Failure class: other
• Last SDK result: (no execution file was produced)

The check is green on purpose, and it is not evidence. It certifies that a security pass ran, and this one did not complete — but the cause is outside this PR's control, so merging is deliberately left unblocked rather than locking every merge for the length of the outage. Nothing was reviewed at this head. Where this check is required, it is satisfied without that evidence; a human should review security-sensitive changes here before merging.

Re-run the job to retry the review; a new push also retries it only if the caller's pull_request triggers include synchronize (the canonical security caller keeps it). An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator.

Re-running does NOT help for every class:

• rate-limit that persists across re-runs, or auth — the credential or usage budget needs an operator; retrying will not clear it.
• a run that exhausted its turn budget ("subtype":"error_max_turns" above) will exhaust it again. As the PR author, split the change into smaller PRs; raising --max-turns is a change to the caller workflow, not something you can set on this PR.