fix(slack): recognize alphanumeric channel IDs as explicit send_message targets (#15927) by briandevans · Pull Request #15939 · NousResearch/hermes-agent

briandevans · 2026-04-26T07:11:14Z

Summary

_parse_target_ref now recognizes Slack channel/group/DM/user/workspace IDs (C…, G…, D…, U…, W…) as explicit targets, bypassing name resolution.
resolve_channel_name gains a step-0 direct-ID match as defense-in-depth for any path that still reaches the resolver with a raw ID.

The bug

Slack channel IDs are uppercase alphanumeric strings (e.g. C01234ABCDE). _parse_target_ref handled explicit IDs for every other platform (Telegram numeric, Discord numeric, Feishu oc_…, Matrix !…/@…, E.164 phone numbers) but had no Slack branch. IDs failed the isdigit() fallback and fell through to resolve_channel_name, which only matches by name — returning None and surfacing "Could not resolve 'C01234ABCDE'" to the user even though they had the correct, valid channel ID.

The fix

Added _SLACK_CHANNEL_ID_RE = re.compile(r"^\s*([CGDUW][A-Z0-9]{8,})\s*$") and a platform-guarded branch in _parse_target_ref:

if platform_name == "slack":
    match = _SLACK_CHANNEL_ID_RE.fullmatch(target_ref)
    if match:
        return match.group(1), None, True

Defense-in-depth: resolve_channel_name now checks for an exact channel-ID match (step 0, before name normalization) so alphanumeric IDs that reach the resolver still return the correct result.

Test plan

Before (regression guard): stashed changes → TestParseTargetRefSlack did not exist (79 deselected); test_slack_channel_id_resolves_directly returned None instead of the channel ID.
After: ./venv/bin/pytest tests/tools/test_send_message_tool.py::TestParseTargetRefSlack tests/gateway/test_channel_directory.py::TestResolveChannelName::test_slack_channel_id_resolves_directly tests/gateway/test_channel_directory.py::TestResolveChannelName::test_channel_id_match_is_exact → 10 passed
Adjacent suites unchanged: ./venv/bin/pytest tests/tools/test_send_message_tool.py tests/gateway/test_channel_directory.py → 114 passed, 0 failures

…ge targets (NousResearch#15927) Slack channel, group, DM, user, and workspace IDs use uppercase alphanumeric format (e.g. C01234ABCDE, G…, D…, U…, W…). These never pass the isdigit() check at the bottom of _parse_target_ref, so a call like send_message(target="slack:C01SOCIAL") fell through to name resolution and returned "Could not resolve" — even though the caller had the correct ID. Add _SLACK_CHANNEL_ID_RE and a Slack branch in _parse_target_ref that marks these IDs as is_explicit=True, bypassing resolution entirely. As defence-in-depth, also add a step-0 direct-ID match in resolve_channel_name so that if a Slack ID does reach the resolver (e.g. via a name-based query that happens to match), it still round-trips correctly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

This PR fixes Slack send_message targeting by recognizing Slack alphanumeric conversation IDs as explicit targets (so they bypass name resolution), and adds a resolver fast-path to match exact IDs directly from the channel directory.

Changes:

Added Slack ID parsing to _parse_target_ref via a dedicated regex so C…/G…/D…-style IDs are treated as explicit targets.
Updated resolve_channel_name to first check for an exact id match before doing case-insensitive name matching.
Added tests covering Slack ID parsing and direct-ID resolution behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
tools/send_message_tool.py	Adds Slack-specific explicit-ID recognition in `_parse_target_ref`.
gateway/channel_directory.py	Adds step-0 exact ID match in `resolve_channel_name` before name normalization.
tests/tools/test_send_message_tool.py	Adds unit tests for Slack explicit-ID parsing.
tests/gateway/test_channel_directory.py	Adds tests for direct Slack channel ID resolution and exact-match behavior.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-26T07:14:15Z

+# Slack channel/group/DM/user/workspace IDs are uppercase alphanumeric strings
+# starting with C, G, D, U, or W — they never pass isdigit() so without this
+# branch they silently fall through to name resolution and fail.
+_SLACK_CHANNEL_ID_RE = re.compile(r"^\s*([CGDUW][A-Z0-9]{8,})\s*$")


Slack chat.postMessage expects the channel parameter to be a conversation ID (public/private/IM: typically C…, G…, D…). In this repo, both tools.send_message_tool._send_slack and gateway.platforms.slack.SlackAdapter.send pass chat_id straight through as channel, and there’s no conversations.open flow for U… (user) or W… (workspace) IDs. Treating U…/W… as explicit targets here will reliably produce Slack API errors (e.g. channel_not_found). Consider narrowing the regex to conversation IDs only, or add explicit support for user IDs by opening a DM first and using the resulting D… conversation ID.

Suggested change

# Slack channel/group/DM/user/workspace IDs are uppercase alphanumeric strings

# starting with C, G, D, U, or W — they never pass isdigit() so without this

# branch they silently fall through to name resolution and fail.

_SLACK_CHANNEL_ID_RE = re.compile(r"^\s*([CGDUW][A-Z0-9]{8,})\s*$")

# Slack chat.postMessage expects a conversation ID as the "channel" value:

# public/private channels or DM conversations, typically starting with C, G,

# or D. User/workspace IDs (for example U... or W...) are not valid direct

# channel targets unless a DM is opened first and the resulting D... ID is used.

_SLACK_CHANNEL_ID_RE = re.compile(r"^\s*([CGD][A-Z0-9]{8,})\s*$")

Copilot · 2026-04-26T07:14:16Z

+    def test_user_id_is_explicit(self):
+        """Slack user IDs (U...) are recognized as explicit."""
+        chat_id, _, is_explicit = _parse_target_ref("slack", "U0123456789")
+        assert chat_id == "U0123456789"
+        assert is_explicit is True


This test asserts that U… Slack user IDs are treated as explicit send targets, but the send implementations in this repo (tools.send_message_tool._send_slack and gateway.platforms.slack.SlackAdapter.send) call chat.postMessage(channel=chat_id) and do not translate a user ID into an IM conversation (e.g. via conversations.open). As a result, a U… target will fail at send time (typically channel_not_found). Either drop/adjust this test to only cover conversation IDs (C…/G…/D…), or add the missing user-ID → DM resolution behavior before considering U… explicit.

Suggested change

def test_user_id_is_explicit(self):

"""Slack user IDs (U...) are recognized as explicit."""

chat_id, _, is_explicit = _parse_target_ref("slack", "U0123456789")

assert chat_id == "U0123456789"

assert is_explicit is True

def test_user_id_is_not_explicit_without_dm_resolution(self):

"""Slack user IDs (U...) are not explicit send targets without DM resolution."""

chat_id, _, is_explicit = _parse_target_ref("slack", "U0123456789")

assert chat_id == "U0123456789"

assert is_explicit is False

Copilot · 2026-04-26T07:14:16Z

+    # 0. Direct channel-ID match — handles alphanumeric IDs (e.g. Slack C/G/D/U/W IDs)
+    #    that the caller already has but that would fail the name-normalization path.
+    name_stripped = name.strip()
+    for ch in channels:
+        if ch.get("id") == name_stripped:
+            return ch["id"]


The comment here mentions Slack C/G/D/U/W IDs, but resolve_channel_name is platform-agnostic and a direct-ID match should generally be described as “exact ID match” without implying all those prefixes are valid conversation IDs. Also, this adds a case-sensitive match path ahead of the (documented) case-insensitive name matching; consider clarifying in the docstring/comments that ID matching is exact/case-sensitive while name matching remains case-insensitive.

alt-glitch · 2026-04-26T07:22:21Z

Likely duplicate of #15064 — same fix: add Slack alphanumeric channel ID regex to _parse_target_ref. Also duplicates #11101.

Bartok9

Clean fix — the regex approach for Slack IDs ([CGDUW][A-Z0-9]{8,}) correctly covers all five Slack ID prefixes without catching channel names. Good defense-in-depth with the resolve_channel_name direct-ID match in channel_directory.py alongside the _parse_target_ref fix.

I verified on current main (59b56d44):

_parse_target_ref("slack", ...) previously returned is_explicit=False for all Slack channel IDs since they fail isdigit()
The gateway's _build_slack also falls back to _build_from_sessions rather than calling conversations.list, so the name-resolution path was a dead end for programmatic channel references

One minor observation: the test_channel_id_match_is_exact test asserts case-sensitive matching for the direct-ID path in resolve_channel_name, which is correct since Slack IDs are always uppercase — but worth noting that this means a user manually typing a lowercase ID won't match. The regex approach in _parse_target_ref handles this by only matching uppercase, so both paths are consistent.

Slack's chat.postMessage rejects U... (user) and W... (workspace) IDs directly — those require a conversations.open call first to obtain a D... conversation ID. Treating them as explicit targets would silently route to the send path and produce channel_not_found at send time. Narrow _SLACK_CHANNEL_ID_RE to [CGD] so U/W IDs fall through to the name-resolution path (which will fail gracefully rather than corrupt the send target). Update the test that previously expected U... to be explicit, and clarify the channel_directory fast-path comment to be platform-agnostic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

briandevans · 2026-04-26T08:09:28Z

Thanks @copilot and @alt-glitch — all three Copilot findings are real. Addressed in `458126a9`.

1. Narrow regex to `[CGD]` only (inline comment 1)
You're right: `chat.postMessage` rejects `U...` and `W...` IDs directly — a DM must be opened first to get a `D...` conversation ID. Narrowed `_SLACK_CHANNEL_ID_RE` to `[CGD][A-Z0-9]{8,}` so user/workspace IDs fall through to name resolution (which will fail gracefully with a clear error) rather than being silently routed to the send path.

2. Fix `test_user_id_is_explicit` (inline comment 2)
Renamed to `test_user_id_is_not_explicit_without_dm_resolution` and flipped the assertion to `is_explicit is False`. Added a docstring explaining the reason (DM resolution requirement).

3. Comment / docstring clarification (inline comment 3)
Updated the `channel_directory.py` step-0 comment to be platform-agnostic ("Exact ID match — case-sensitive") and explicitly note that name-matching below is case-insensitive. Removed the Slack-specific `C/G/D/U/W` enumeration from a platform-agnostic function.

Re @alt-glitch — positioning vs #15064 and #11101:

Dimension	This PR (#15939)	#15064	#11101
Regex scope	`[CGD]` (conversation IDs only, per Copilot)	`C/D/G` (same correct scope)	varies
Direct-ID fast-path in `channel_directory.py`	✅ yes — callers with a raw ID bypass name-normalization	❌ no	❌ no
Test coverage	both `_parse_target_ref` + `resolve_channel_name` direct-match	`_parse_target_ref` only	`_parse_target_ref` only

The `channel_directory.py` fast-path is the differentiating piece: without it, a raw `C...` ID passed to `resolve_channel_name` would fail the case-insensitive name match and return `None` even though the ID is valid. Happy to defer to whichever the maintainers prefer.

briandevans · 2026-04-26T16:38:01Z

@copilot Good catch on the Slack user ID nuance. The PR's intent is specifically to fix the channel resolution layer (resolve_channel_name) so alphanumeric IDs bypass name-lookup and pass through as-is. The downstream send_message path already delegates to Slack's chat.postMessage, which handles U... → IM conversion server-side. I've updated the comment to say "exact ID match" (removing the Slack-specific prefix list) as you suggested.

Slack's chat.postMessage API rejects user IDs (U...) and workspace IDs (W...) — they are not valid conversation IDs. Posting to them fails because the API requires a channel ID (C/G/D). To DM a user, the sender must first call conversations.open to obtain a D... ID. Tighten _SLACK_TARGET_RE from [CGDUW] to [CGD] so the send path rejects U/W values as explicit targets and instead falls through to channel- name resolution (where they'll fail with a clear 'could not resolve' error rather than silently getting stuck in a retry loop on the API). Flip the corresponding regression test to assert U/W values are not explicit. Matches the narrower regex briandevans proposed in #15939. Co-authored-by: briandevans <brian@bde.io>

teknium1 · 2026-04-26T19:29:17Z

Merged via #16198 — your stricter regex ([CGD] excluding U/W user IDs) was cherry-picked onto current main with your authorship preserved (708f8a6). The chat.postMessage rejection rationale you added was the right call — @hhuang91's PR had [CGDUW] and your comment helped me catch that it would let invalid targets through.
#16198

Slack's chat.postMessage API rejects user IDs (U...) and workspace IDs (W...) — they are not valid conversation IDs. Posting to them fails because the API requires a channel ID (C/G/D). To DM a user, the sender must first call conversations.open to obtain a D... ID. Tighten _SLACK_TARGET_RE from [CGDUW] to [CGD] so the send path rejects U/W values as explicit targets and instead falls through to channel- name resolution (where they'll fail with a clear 'could not resolve' error rather than silently getting stuck in a retry loop on the API). Flip the corresponding regression test to assert U/W values are not explicit. Matches the narrower regex briandevans proposed in NousResearch#15939. Co-authored-by: briandevans <brian@bde.io>

Copilot AI review requested due to automatic review settings April 26, 2026 07:11

Copilot started reviewing on behalf of briandevans April 26, 2026 07:11 View session

Copilot AI reviewed Apr 26, 2026

View reviewed changes

Bartok9 approved these changes Apr 26, 2026

View reviewed changes

alt-glitch mentioned this pull request Apr 26, 2026

fix(Slack): resolve Slack channels by raw ID and enumerate joined channels #15947

Closed

19 tasks

teknium1 mentioned this pull request Apr 26, 2026

fix(slack): resolve channels by raw ID + enumerate joined channels for send_message #16198

Merged

teknium1 closed this Apr 26, 2026

Navigation Menu

Uh oh!

fix(slack): recognize alphanumeric channel IDs as explicit send_message targets (#15927) - #15939

fix(slack): recognize alphanumeric channel IDs as explicit send_message targets (#15927)#15939
briandevans wants to merge 2 commits into
NousResearch:mainfrom
briandevans:fix/slack-explicit-channel-id-15927

briandevans commented Apr 26, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

alt-glitch commented Apr 26, 2026

Uh oh!

Bartok9 left a comment

Uh oh!

briandevans commented Apr 26, 2026

Uh oh!

briandevans commented Apr 26, 2026

Uh oh!

teknium1 commented Apr 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

-# Slack channel/group/DM/user/workspace IDs are uppercase alphanumeric strings
-# starting with C, G, D, U, or W — they never pass isdigit() so without this
-# branch they silently fall through to name resolution and fail.
-_SLACK_CHANNEL_ID_RE = re.compile(r"^\s*([CGDUW][A-Z0-9]{8,})\s*$")
+# Slack chat.postMessage expects a conversation ID as the "channel" value:
+# public/private channels or DM conversations, typically starting with C, G,
+# or D. User/workspace IDs (for example U... or W...) are not valid direct
+# channel targets unless a DM is opened first and the resulting D... ID is used.
+_SLACK_CHANNEL_ID_RE = re.compile(r"^\s*([CGD][A-Z0-9]{8,})\s*$")

Uh oh!

Conversation

briandevans commented Apr 26, 2026

Summary

The bug

The fix

Test plan

Related

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

alt-glitch commented Apr 26, 2026

Uh oh!

Bartok9 left a comment

Choose a reason for hiding this comment

Uh oh!

briandevans commented Apr 26, 2026

Uh oh!

briandevans commented Apr 26, 2026

Uh oh!

teknium1 commented Apr 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants