[john-the-dev]

Summary

• Finding README: inline demo video #4 from workspace/notes/security-audit-2026-07-06.md: the outer except Exception in __main__ of hooks/context-source-guard.py would fail-open on any unhandled exception, including one that occurs after a non-empty contextNotFrom blacklist has been confirmed.
• Any runtime error inside the channel-check loop (guild resolution, token lookup, membership test) could silently allow a blacklisted …/channels/<id>/messages read through.
• Blast radius is narrow (channel message reads only), but the bypass is deterministic if an exception can be induced after the blacklist check.

Fix in hooks/context-source-guard.py:

• Wrap the critical section (entered once blacklist is confirmed non-empty) in a scoped try/except that calls _deny() on any non-SystemExit exception.
• Pre-check errors (stdin JSON parsing, tool-type detection, serving-channel lookup, blacklist load) still flow to the outer fail-open handler — correct behaviour because no guard is active yet.
• except SystemExit: raise ensures _deny()'s sys.exit(0) propagates normally through the inner block.
• Updated module docstring and comment to reflect the tightened exception policy.

New test 9 in tests/context-source-guard.test.py:

• Imports the hook as a module, seeds serving state to a channel with a non-empty blacklist, monkey-patches _resolve_guild to raise RuntimeError, feeds a matching channel-read payload, and asserts the hook denies (fails-closed) rather than allowing.

Test plan

• python3 tests/context-source-guard.test.py — all 9 tests pass (including new test 9 which explicitly exercises the RuntimeError → deny path)
• Existing tests 1–8 unchanged: channel-level deny, guild-level deny, fail-closed on unresolvable guild, plain bash pass-through, cat-path serving detection, SUTANDO_WORKSPACE ignored (feat(discord-bridge): contextNotFrom gate — bar a channel from pulling context from blacklisted channels/guilds #1698), per-host CLAUDE_CONFIG_DIR walk (feat(discord-bridge): contextNotFrom gate — bar a channel from pulling context from blacklisted channels/guilds #1698)

🤖 Generated with Claude Code

https://claude.ai/code/session_01QB3qZQrwponfum2JFNvHeh

[github-actions]

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 48%.

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

No lines with coverage information in this diff.

[qingyun-wu]

Cold-reviewed — fix is correct; one non-blocking test-precision note.

Fix (hooks/context-source-guard.py) — correct and important. Wrapping the post-blacklist-confirmed critical section in its own try/except closes the fail-open bypass: previously any exception from _token()/_resolve_guild() after a non-empty blacklist was confirmed unwound to the top-level except → sys.exit(0) (fail-open = allow a potentially-blacklisted read). Now it fails closed via _deny(). ✅

• except SystemExit: raise correctly lets _deny()s exit propagate — and since SystemExit derives from BaseException (not Exception), the except Exception arm couldnt swallow a deny even without the explicit re-raise. Nicely double-safe.
• Splitting fail-open (pre-check: parsing/serving lookup) from fail-closed (guard-active) is the right boundary, and the docstring update matches.

Test note (non-blocking): test #9 asserts SystemExit.code == 0 was raised. Sound for this setup — _resolve_guild throws on the first target, so exit(0) can only come from _deny(), and the old code would escape main() as a RuntimeError (not SystemExit) → assertion fails → regression caught. But exit(0) is also what a fail-open allow emits, so the assertion is indirect. Consider redirecting stdout and asserting the deny payload is actually emitted — makes it assert deny-content rather than an exit happened. Nice-to-have.

No blockers — recommend merge. Merge stays your call.

[qingyun-wu]

Automated mergeability review (2026-07-09)

Signal: NOT MERGEABLE

Current blocker(s):

• Branch is behind current main; update/merge main and rerun checks before merging.

This is a conservative backlog triage signal. After the blockers are cleared, please rerun checks and request a focused review.

[liususan091219]

Codex full-review sweep: checked against the 7 triage CR classes (source-grep tests, incomplete fix, band-aid, naming, false claim, live-test policy, hardcoded paths) - none fire. Approving.

review-reason: codex-clean per full-review sweep

Approval withheld pending owner go (resequenced: CRs first). Will re-approve.

[qingyun-wu]

LGTM. I diffed this against main and ran python3 tests/context-source-guard.test.py in the PR worktree; it passed, including the new injected-exception case inside the guarded section. The inner try/except now closes the fail-open hole without changing the intended pre-check fail-open behavior at process entry.

Qingyun's Personal Codex Agent

[liususan091219]

Independent before/after verification (maintainer): imported the hook as a module, seeded a serving channel with a non-empty contextNotFrom blacklist, monkey-patched _resolve_guild to raise inside the gated section, and fed a matching …/channels/999/messages Bash read (999 not directly in the blacklist, so it reaches guild resolution). Ran each version through its own __main__ wrapper.

BEFORE (origin/main):

[main] result -> ALLOW (fail-open) ⚠  [outer except allowed: True]

The exception escapes the (unwrapped) gated block → hits the outer except Exception → prints "allowing" and exits 0. The blacklisted channel read is permitted despite an active guard — exactly finding #4.

AFTER (this PR):

[1985] result -> DENY (fail-closed) ✅

The scoped try/except catches it and emits permissionDecision: deny. The read is blocked (fail-closed). except SystemExit: raise confirmed intact (a normal _deny still propagates).

Confirms the security claim: an exception after a non-empty blacklist is confirmed now fails closed instead of open. Verified working.

[github-actions]

@cla-assistant check