Description

On NemoClaw v0.0.55, when a Slack human user not present in SLACK_ALLOWED_USERS sends an explicit @-mention to the NemoClaw bot, the gateway logs a Unauthorized user warning and silently drops the message. The bot does not reply (or DM, or react) to the sender, so from the user's side the bot appears completely unresponsive.

The recently-landed fix described as "Changed Slack bot-message handling to mentions, so CI bots can trigger replies when they explicitly mention Nemoclaw" only covers the bot-origin (bot_id-tagged) message path; it does NOT bypass SLACK_ALLOWED_USERS for human-origin @-mentions.

Confirmed on Holly Lu's sandbox (host lab@10.33.3.180, sandbox name nemoclaw-nvcf) with Cindy Jiang (Slack user id U023JAY9WGZ) attempting three @-mentions in sequence — all dropped.

Environment

Device:        Holly Lu's host lab-swqa (lab@10.33.3.180)
OS:            Ubuntu 24.04.4 LTS
Architecture:  x86_64
Node.js:       v18.19.1 (system /usr/bin/node)
npm:           N/A (not relevant to runtime issue)
Docker:        29.5.2 (build 79eb04c)
OpenShell CLI: 0.0.44
NemoClaw:      v0.0.55 (nemoclaw + nemohermes shims both present)
OpenClaw:      N/A — running Hermes Agent v0.14.0 (build 2026.5.16, Python 3.13.5)
Sandbox:       nemoclaw-nvcf (default), gateway PID 11128 alive ~21h

Steps to Reproduce

1. Set up a NemoClaw v0.0.55 sandbox with Slack integration. SLACK_ALLOWED_USERS in /sandbox/.hermes/.env contains a small set of authorized user ids (~4-5 users) and explicitly does NOT include the test user's id.

2. As a Slack human user whose user id is NOT in SLACK_ALLOWED_USERS (in this case U023JAY9WGZ — Cindy Jiang), @-mention the NemoClaw bot in a channel where the bot is invited, e.g.:

   @nemoclawtest hello
   

3. Observe the bot's behavior in Slack — bot does not respond, no DM, no reaction, no error to sender.

4. On the host, check the sandbox gateway log:

   docker exec <CID> tail -100 /sandbox/.hermes/logs/gateway.log

   The inbound event is observed and rejected with:

   WARNING gateway.run: Unauthorized user: U023JAY9WGZ (Cindy Jiang) on slack
   

5. Repeat step 2 — bot remains silent across multiple attempts. Each attempt produces another Unauthorized user warning in the log.

Expected Result

At least one of the following:

• (a) The "explicit-mention bypass" implied by the commit description "Changed Slack bot-message handling to mentions, so CI bots can trigger replies when they explicitly mention Nemoclaw" applies uniformly to all explicit @-mentions — human-origin and bot-origin alike. The bot would respond to Cindy's mention.

• (b) If SLACK_ALLOWED_USERS is intentionally meant to block human @-mentions too, the bot should at least give the sender ONE feedback message (DM or ephemeral) explaining that they need to be added to SLACK_ALLOWED_USERS. The current behavior of completely silent drop is a UX dead-end — the user has no idea their message was even seen.

Either (a) or (b) is acceptable; current behavior (silent drop with log-only feedback) is not.

Actual Result

Gateway receives the @-mention event, evaluates SLACK_ALLOWED_USERS allowlist, decides the sender is unauthorized, and silently drops the message. Sender (Cindy Jiang) sees nothing in Slack — no reply, no DM, no error. Only the host-side gateway log records the rejection:

WARNING gateway.run: Unauthorized user: U023JAY9WGZ (Cindy Jiang) on slack

Repeated 3 times in the supplied log excerpt — Cindy tried three messages, all dropped silently.

Important context — the fix described in chat as "Changed Slack bot-message handling to mentions, so CI bots can trigger replies when they explicitly mention Nemoclaw" was clearly intended to make explicit @-mention the trigger that allows otherwise-filtered messages through. But it only addresses bot-origin (messages with bot_id set) paths. Human-origin messages with explicit @-mention still go through the standard user-authorization check and are dropped when the sender is not on the allowlist.

PR/commit reference for the original fix: TBD — Holly Lu / the original implementer can supply this on the bug for cross-link.

Workaround for the immediate user: add the affected user's Slack id to SLACK_ALLOWED_USERS and rebuild the sandbox (or reload the env if hermes supports hot reload). This sidesteps the UX gap but does not address the underlying design question: should explicit @-mention bypass the user allowlist at all?

Logs

[from Holly Lu's sandbox gateway log, contiguous excerpt]

[1780537530.514] [sandbox] [OCSF ] [ocsf] HTTP:POST [INFO] ALLOWED POST http://slack.com:443/api/chat.update [policy:slack engine:l7]
[1780537531.116] [sandbox] [OCSF ] [ocsf] NET:OPEN [INFO] ALLOWED /usr/bin/python3.13(11128) -> slack.com:443 [policy:slack engine:opa]
[1780537531.147] [sandbox] [OCSF ] [ocsf] HTTP:POST [INFO] ALLOWED POST http://slack.com:443/api/assistant.threads.setStatus [policy:slack engine:l7]
[1780537537.285] [sandbox] [OCSF ] [ocsf] NET:OTHER [INFO] ALLOWED wss-primary.slack.com:443 [policy:slack engine:l7-websocket]
[1780537538.700] [sandbox] [OCSF ] [ocsf] NET:OTHER [INFO] ALLOWED wss-primary.slack.com:443 [policy:slack engine:l7-websocket]

(...several slack_bolt "Unhandled request" warnings for channel_rename and app_home_opened events — bot subscribed to events it has no handlers for; possibly a separate bot-config issue and not central to this bug...)

WARNING gateway.run: Unauthorized user: U023JAY9WGZ (Cindy Jiang) on slack
WARNING gateway.run: Unauthorized user: U023JAY9WGZ (Cindy Jiang) on slack
WARNING gateway.run: Unauthorized user: U023JAY9WGZ (Cindy Jiang) on slack

(The three Unauthorized user lines are interleaved with channel_rename and app_home_opened warnings in the original log — those events are noise from over-broad slack event subscriptions, unrelated to the core bug.)

[from /sandbox/.hermes/.env on the same sandbox, values hidden — only key + length]

SLACK_BOT_TOKEN=<42 chars>
SLACK_APP_TOKEN=<42 chars>
SLACK_ALLOWED_USERS=<59 chars>      # ~4-5 user ids; explicitly does NOT include U023JAY9WGZ
SLACK_ALLOWED_CHANNELS=<23 chars>   # 1-2 channel ids

Related but distinct issue, mentioned for context:

NVB 6180485 (Open) [Ubuntu 24.04][Agent&Skills] NemoHermes Slack socket-mode idle reconnect silently drops inbound @mention messages — that bug is about messages being dropped after a Socket Mode reconnect; this bug is about messages being dropped by the SLACK_ALLOWED_USERS allowlist even on a healthy socket. Different code paths.

NVB#6266593