[liususan091219]

What

Adds an information-flow gate to the Discord-state prefetch. A channel can declare, in access.json, which channels/guilds its replies must not pull context from.

This mirrors allowFrom's per-channel shape but on a different axis:

• allowFrom = who may send a task in this channel.
• contextNotFrom = which sources may feed a reply in this channel.

How

• load_channel_context_blacklist(channel_id) reads the per-channel contextNotFrom set from access.json.
• _prefetch_discord_state_refs(text, origin_channel_id) now skips any referenced channel whose channel-id OR guild-id is in the originating channel's contextNotFrom. Guild-aware: a single guild id blocks every channel in that guild (including future ones) — no enumeration.

Config example

"groups": {
  "<#dev channel id>": {
    "requireMention": false,
    "allowFrom": ["...user ids..."],
    "contextNotFrom": ["<private guild id>"]
  }
}

→ a task in #dev can never pull any channel in that private guild, even if the task text references one.

Scope / follow-up

The prefetch currently runs for team/other-tier tasks; extending the gate to cover owner-tier public-channel tasks is a follow-up (noted, not in this PR).

Test

python3 -m py_compile src/discord-bridge.py passes. Additive field — existing access logic (allowFrom/requireMention) is unchanged; only the new gate reads contextNotFrom.

🤖 Generated with Claude Code

[sonichi]

Cold review (Pro) — contextNotFrom context-isolation gate. Strong feature, right design (serving-relative: a private channel can still read itself; only cross-context pulls are barred; guild-level entries block a whole guild incl. future channels; applies to all tiers incl. owner for context-build). Good test coverage. One should-fix on the backstop, plus two limitations worth noting.

[should-fix] The hook (context-source-guard.py) hardcodes legacy paths, so on a relocated install it reads a different access.json than the bridge writes — and silently fails open.

Two of the three new components resolve config correctly: read_discord_channel.py uses claude_home_path("channels","discord","access.json"), and discord-bridge.py's load_channel_context_blacklist uses the module ACCESS_FILE (also claude_home_path). But the hook hardcodes:

ACCESS_FILE = os.environ.get("SUTANDO_DISCORD_ACCESS_FILE", os.path.expanduser("~/.claude/channels/discord/access.json"))
WS = os.path.expanduser(os.environ.get("SUTANDO_WORKSPACE", "~/.sutando/workspace")...)

On a node where $CLAUDE_CONFIG_DIR is relocated (verified on a live host: bridge reads $CLAUDE_CONFIG_DIR/channels/discord/access.json, hook reads ~/.claude/channels/discord/access.json — both happen to exist, so the hook reads the stale legacy copy), a contextNotFrom configured operationally through the bridge's path is invisible to the hook → _blacklist() returns empty → fail-open. Since the hook is explicitly the backstop for the one path an instruction can't force (a raw curl), that's the component you least want failing open. (SUTANDO_WORKSPACE is also the env var dropped for resolution in v0.8/#1440, and ~/.sutando/workspace is the pre-M0 default.) Fix: resolve ACCESS_FILE/ENV_FILE from $CLAUDE_CONFIG_DIR (with the ~/.claude fallback) and WS via the M0 workspace helper, matching the other two components.

[limitation] Serving-state is a single global file, last-write-wins. active-serving-channel.json is set by whichever task-file Read/cat happened most recently. Under interleaved/concurrent task processing the "serving" channel a curl is checked against can be stale — a read while serving B could be evaluated against A's blacklist. Fine as best-effort defense-in-depth (the threat model is the agent's own reads, not an adversary), but it's a heuristic, not an airtight boundary — worth stating that explicitly.

[limitation] The Bash guard only matches channels/<id>/messages. A curl …/channels/<id> (channel metadata), a websocket, or an alternate fetch wrapper slips the regex. It's layered with the gated reader + CLAUDE.md instruction, so it's not the only line — but the hook's raw-curl coverage is narrower than "any channel read."

Posture note: the overall design is fail-open by intent (missing token / unknown serving / malformed access.json → allow); the one fail-closed case (blacklist applies + guild unresolvable) is the right call.

Bottom line: ship-worthy after the hook path-resolution fix — without it the backstop no-ops on exactly the relocated installs the rest of the revamp targets. No merge authority — flagging for @sonichi.

[liususan091219]

Pushed cdb0a1a6 addressing the review comment: the context-source-guard hook now resolves ACCESS_FILE/ENV_FILE from $CLAUDE_CONFIG_DIR (fallback ~/.claude), matching read_discord_channel.py/discord-bridge's claude_home_path — so it no longer fails OPEN on a relocated install. No behavior change on a default install.

[github-actions]

@cla-assistant check