[amkunte]

Problem

discord-bridge.py reads DISCORD_BOT_TOKEN exclusively from ~/.claude/channels/discord/.env at module-load time. There is no fallback to os.environ. This causes test suites that inject a stub token via os.environ.setdefault("DISCORD_BOT_TOKEN", "test-token-not-real") to fail with:

DISCORD_BOT_TOKEN not set in ~/.claude/channels/discord/.env

Affects VasiliyRad PRs #1046 (bridges-sending-orphan-recovery.test.py) and #1048 (discord-bridge-delivery-sentinel.test.py) — both set the env var before import but the bridge never checked it.

Fix

Check os.environ.get("DISCORD_BOT_TOKEN") first; fall back to the .env file. This is the same pattern already used by telegram-bridge.py (lines 102–104).

Impact

• Unblocks CI on fix(bridges): recover orphan .sending files on startup (restart-safety) #1046 and fix(discord-bridge): delivery-idempotency sentinel for poll_results (restart-safety) #1048 (their tests already do the right thing — the bridge just needs to cooperate)
• Operators who set DISCORD_BOT_TOKEN as a real env var now get it picked up without needing the file
• No behavior change for existing deployments that use the .env file

🤖 Generated with Claude Code

[qingyun-wu]

LGTM — this is the right, minimal fix and correctly diagnosed. Env-var-takes-precedence with .env fallback is the standard "env overrides config file" precedence, the exit(1) when neither is set is preserved, and it's appropriately surgical (8/-7, one file). CI is green.

This is effectively the keystone for the restart-safety series: it unblocks #1046's CI directly. One nuance worth flagging — it's necessary but not sufficient for #1048: that test imports the bridge without stubbing the discord module (whereas #1046 does), so after this lands #1048 will likely still fail at import discord until it adds the stub. (Raised that on #1048.)

Two minor, non-blocking nits:

1. Strip consistency. The .env path does .split("=", 1)[1].strip(), but the new env-var path doesn't strip — os.environ.get("DISCORD_BOT_TOKEN", ""). A stray trailing newline in the env var would slip through. Consider .strip() for parity: os.environ.get("DISCORD_BOT_TOKEN", "").strip().
2. Error message. Now that the env var is also consulted, the failure message ("DISCORD_BOT_TOKEN not set in ~/.claude/channels/discord/.env") is slightly misleading — it doesn't mention the env var that was also checked. e.g. "DISCORD_BOT_TOKEN not set (checked env var and ~/.claude/channels/discord/.env)" would aid debugging.

Neither blocks. Nice clean fix.