Bug: ALLOWED_CHAT_IDS env var propagation

[dmibaranov]

Description

The current implementation fails to propagate the ALLOWED_CHAT_IDS environment variable to the Telegram bridge child process. This results in a security bypass where any user can interact with the bot regardless of the whitelist settings.

Reproduction Steps

$ env | grep ALLOWED
ALLOWED_CHAT_IDS=<redacted>
$ nemoclaw start
[services] telegram-bridge started (PID 42541)
...
$ ps -wwp 42541 -E | grep ALLOWED || echo "missed"
missed

Environment

• OS: macOS 26.3.1
• Node.js: v25.2.1
• Docker: Docker Desktop 4.62.0, Engine 29.2.1
• NemoClaw: v0.1.0

Debug Output

Logs

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate

[wscurran]

✨ Thanks for submitting this issue with a detailed summary, it addresses a bug with the Telegram bridge failing to propagate the ALLOWED_CHAT_IDS environment variable, which could be related to the Telegram integration or security configuration.

---

Possibly related open PRs:

• #860 fix: queue telegram bridge messages per chat to prevent session lock contention
• #812 fix: bake CHAT_UI_URL into Docker build for remote dashboard access
• #699 fix(security): require explicit opt-in for Telegram bridge open chat access

[WuKongAI-CMU]

I rechecked the current main service-launch path with a minimal harness and the telegram-bridge child still sees ALLOWED_CHAT_IDS in its environment. That suggests this may have been an older-install or older-script-path issue rather than a current main regression. If someone can still reproduce it on current main, the next useful artifact would be the exact launch path plus the bridge child environment from that run.

[prekshivyas]

@dmibaranov can you confirm if you are still seeing this issue with the latest release?