Why this fails even when messages can already be sent elsewhere
n8n's Slack node channel-selector dropdown is powered by a separate API call (conversations.list) from the one used to actually post a message (chat.postMessage). A bot token can have chat:write without channels:read, which lets manual channel-ID entry work for sending while the dropdown itself stays empty or errors — this is why the failure feels inconsistent between nodes that already work and a newly added one that will not populate its picker.
Community reports specifically note this resolving after adding scopes that were not in the originally suggested list when the app was first created, which suggests the minimal-scope guidance many users start from does not include everything the picker needs.
Add the required read scopes and reinstall
- Add channels:read for public channel listing.
- Add groups:read if the workspace uses private channels you need to select from the dropdown.
- Reinstall the app to the workspace after adding scopes — Slack does not apply new scopes to a token until reinstall, same as with event subscriptions.
- Reconnect or refresh the credential in n8n after reinstalling so it picks up the newly scoped token rather than caching the old permission set.
If you cannot add scopes immediately, use manual entry
The Slack node typically allows manually typing or pasting a channel ID instead of relying on the dropdown, which works with only chat:write if the bot is already a member of that channel. This is a valid short-term workaround while scope changes go through an approval process, but treat it as temporary — a manually entered ID does not get validated against the live channel list, so a typo or a since-archived channel will not be caught until the node actually runs.
# Manual channel entry format in the Slack node's Channel field:
# Use the raw channel ID, not the #channel-name:
C0123456789
# NOT: #general
# NOT: general
# Get the ID from Slack: right-click channel -> View channel details -> scroll to bottom
Why scope requirements drift between app-creation methods
Slack apps can be created from a blank scope set, from a template, or from an app manifest — and each starting point suggests a different minimal scope list. An app created from a basic "send messages" template commonly ships with only chat:write and none of the conversations.list-dependent read scopes, because sending was the only demonstrated use case at creation time. If you inherited an existing Slack app rather than creating it fresh for this workflow, check its full scope list against what the specific n8n operations you are using actually require, rather than assuming an app that already sends messages successfully has everything the node needs.
Sources checked for this guide
The scope requirement is consistent with Slack's documented conversations.list permissions model; the specific n8n symptom reports are below.
Frequently asked questions
Why can I send messages but the channel dropdown still won't load?
Sending uses chat:write; the dropdown uses a separate conversations.list call that needs channels:read (and groups:read for private channels). Having one scope does not imply the other.
Do I need to recreate the Slack app to add these scopes?
No. Add the scopes on the existing app's OAuth & Permissions page, then reinstall the app to the workspace — recreating the app is not necessary and would lose the existing app identity.
Is manually typing a channel ID a safe permanent fix?
It works as a short-term workaround if the bot already has chat:write and channel membership, but it is not validated against the live channel list, so treat it as temporary until the read scopes are added.
What format does the manual channel ID field expect?
The raw channel ID (like C0123456789), not the #channel-name display form. Find it in Slack under the channel's "View channel details" panel.
