Feature request: Slack plugin inbound mentions/DMs should wake a Codex Desktop thread

Open 💬 4 comments Opened Apr 30, 2026 by Meh-S-Eze

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Duplicate / relationship note

This is related to #20312, #15299, #15355, #14923, and #18929, but it is not intended as a duplicate of any one of them.

The distinction: those issues describe lower-level platform primitives such as event-driven session wake, inbound MCP notifications, trusted local ingress, app-server/thread orchestration, or daemon-agent push/pull coordination. This issue asks for the user-facing Slack plugin/Desktop product behavior that could be built on top of those primitives: inbound Slack DMs and app_mention events should wake or notify a selected Codex Desktop thread, display the Slack source message with attribution/channel/link, and optionally allow a Slack bot reply.

What feature would you like to see?

I would like the Codex Slack plugin to support inbound Slack events, not only read/search/send actions initiated from Codex.

Example: when someone DMs the Codex Slack app or mentions it in a channel, Codex should be able to wake a chosen Codex Desktop thread, show the Slack message in that thread, and let the user review or continue the workflow from Codex.

Current limitation

The Slack connector can send messages, draft messages, and read/search Slack when Codex is already running. But it does not appear to let Slack messages proactively enter the Codex Desktop conversation as user-visible events.

Why this matters

For team workflows, Slack is often where the request starts. I want Codex to act as a Slack-aware assistant while still keeping the human in the loop inside Codex Desktop. The important UX is not just autonomous replies in Slack, but seeing the inbound Slack message and Codex's processing inside the Codex UI.

Desired behavior

Configure a Slack workspace/channel/DM as a source.
Receive app_mention and DM events.
Wake or notify a selected Codex thread.
Display the Slack message with attribution, channel, and link.
Let the user approve, respond, or take over from Codex Desktop.
Optionally allow Codex to reply back to the originating Slack thread as the bot.

Safety expectations

Explicit opt-in per workspace/channel.
Clear identity separation between the user and the bot.
No automatic posting unless enabled.
Audit trail linking Codex actions to the Slack source message.

Related platform capability

This may also benefit from a more general Codex Desktop local input/wakeup API, such as a local authenticated endpoint, custom URL scheme, or app-server method that lets trusted integrations append a user-visible turn to a selected thread.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#20312

Powered by Codex Action

Meh-S-Eze · 3 months ago

Thanks for the duplicate detection. I looked through the nearby requests and I think this issue is related to a broader cluster, but captures a distinct product-level Slack/Desktop use case.

Related issues:

#20312 asks for the broad primitive: native event-driven session wake from external sources such as chat mentions, queues, file changes, MCP pushes, sockets, or process output.
#15299 asks for inbound MCP notifications to be routed into an active Codex CLI session.
#15355 asks for opt-in local ingress for trusted local controllers into an interactive CLI/TUI session, without PTY/keyboard emulation.
#14923 asks for Desktop/app-server cross-thread orchestration over existing thread/turn primitives.
#18929 asks for a persistent workspace daemon agent that can push important events back to the main agent.

This issue is narrower and more product-facing: the Codex Slack plugin should support inbound Slack DMs or app_mention events in Codex Desktop, wake or notify a selected Desktop thread, display the Slack message with attribution/channel/link, and optionally let Codex reply back through Slack as the bot.

If the right implementation path is “build #20312 or a similar wake/input primitive first, then wire Slack inbound events on top,” that makes sense. I opened this separately to preserve the Slack-specific UX and safety expectations.

prassanna-ravishankar · 2 months ago

the inbound-mention-wakes-a-thread direction is the bit that turns slack from a notifier into an actual control surface, agreed.

repowire ships a slack bot peer that does this for CLI sessions today: an inbound mention/DM routes to the target session and wakes it, with the reply coming back to the thread. attribution and a bot reply path are both there.

honest caveat: repowire routes to mesh peers (CLI sessions on a daemon), not to codex desktops native thread model, so its an external answer rather than the desktop-thread-native behaviour youre asking for. but if the goal is slack-mention -> wake a running codex session, the mechanism exists now.

alexfrmn · 2 months ago

Related: this is CLI-only and does not claim to solve Codex Desktop or Slack plugin wake behavior, but it may be a reusable lower-level ingress primitive for channel-style integrations.

Patch: https://github.com/openai/codex/compare/main...alexfrmn:upstream-pr-mcp-surface-notifications?expand=1