›_ Codex Issues
Codex Issues / #30744

Slack integration blocks the core use case: posting user-approved messages

Open 💬 3 comments Opened Jun 30, 2026 by azolotov

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.623.70822

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

I asked Codex to post a message to Slack in a user-selected channel. That is the main purpose of the Slack integration: I want Codex to be able to send Slack messages when I explicitly ask it to.

What happened:

  • I asked Codex to post an internal operational update to a Slack channel.
  • The Slack send was rejected as “unacceptable risk” because the message contained internal engineering/deployment details.
  • Codex then asked me to explicitly confirm that I wanted it posted.
  • I replied with explicit confirmation.
  • Codex retried the Slack send.
  • The second attempt was rejected again, saying the disclosure was denied even with explicit user approval.
  • Nothing was posted.

This makes the Slack integration unusable for one of its core workflows: sending a user-approved Slack message.

What steps can reproduce the bug?

Feedback ID: 019f196a-b8eb-7f72-ae1e-99a20e1c37be

What is the expected behavior?

If I explicitly ask Codex to post to Slack, and then explicitly confirm after being warned, Codex should be able to post the message to the selected Slack channel.

Internal engineering updates to internal Slack channels are a normal and expected use case for this integration.

Additional information

Actual behavior:

  • The Slack integration blocks the post even after explicit approval.
  • The rejection guidance is contradictory: it suggests explicit user approval may unblock the action, but enforcement still blocks it.

Impact:

  • I cannot rely on Codex to post operational updates to Slack.
  • The tool forces manual copy/paste for exactly the workflow it is supposed to automate.
  • It creates confusion because Codex asks for confirmation, but confirmation does not help.

Suggested fix:

  • Allow user-approved Slack posts to user-selected Slack channels.
  • If the policy needs an approval step for sensitive/internal content, the approval should actually unblock the send.
  • If some content can never be sent, the tool should say that immediately and should not suggest explicit approval as a path forward.

View original on GitHub ↗

3 Comments

jameswasher · 1 month ago

We reproduced this today, with an additional detail that suggests the safety check is being applied inconsistently rather than enforcing a stable connector or workspace permission.

  • The same Codex desktop setup successfully posted more than 10 merge/deployment announcements to the same internal Slack channel the previous evening.
  • The successful messages used the same Slack connector, authenticated workspace, channel ID, and auto_review permission profile.
  • Several successful messages contained more detailed issue, PR, validation, and production-deploy information than the messages that were later blocked.
  • A few hours later, similar announcements to that same channel were rejected because Slack was classified as an "unverified external destination."
  • The user explicitly approved the posts, including a standing instruction to post these release announcements, but the retry was rejected "even with explicit user approval."
  • We then reduced the operation to one short announcement for one issue in one Slack call. That standalone call was rejected for the same reason, and the policy response prohibited attempting the remaining messages.

Nothing observable changed in the Slack destination, authentication, connector, requested action, or information category between the successful and rejected calls. The only apparent difference was that the calls occurred in separate Codex tasks and were evaluated again.

This makes the behavior especially difficult to understand and rely on: an identical normal workflow can succeed repeatedly and then become impossible hours later, while the rejection message first suggests approval may help and subsequently says approval cannot override it. The safety decision should be deterministic for the same authorized destination and workflow, and an explicit user confirmation should either unblock the send or never be presented as a possible resolution.

maguroid · 1 month ago

Reproduced on Codex runtime/CLI 0.144.6 in the macOS desktop app (Apple Silicon).

Additional environment details:

  • Personal Mac, not enrolled in DEP or MDM.
  • No /etc/codex/requirements.toml.
  • No local auto-review rule that denies Slack actions.
  • ChatGPT authentication with the installed Slack connector.

Reproduction:

  1. Resolve a deliberately selected channel through the authenticated Slack connector.
  2. Ask Codex to post a routine status update whose text the user has reviewed.
  3. Explicitly approve the send.
  4. The first send is rejected because Slack is classified as an untrusted external destination.
  5. After the user explicitly confirms again, the retry is rejected with wording that the action is not permitted even with user approval.
  6. Nothing is posted.

The actual message body, organization name, channel name, account identifiers, and repository paths are intentionally omitted from this public report.

A related auto-review false positive also occurs when Codex invokes claude -p for an explicitly authorized workflow. That behavior closely matches #34007, suggesting this may be a broader auto-review destination-classification problem rather than a Slack-specific permission issue.

Expected behavior:

  • A user-selected, authenticated connector destination should not be treated as unexpected exfiltration.
  • Explicit approval (including the supported /approve flow) should either permit one retry or the UI should clearly state upfront that the action is non-overridable.
  • The decision should be consistent across equivalent runs.

Natural-language approval did not unblock this reproduction; /approve has not yet been tested in this specific thread.

azolotov · 1 month ago

This is still happening.

It’s not limited to shell commands. I see it with multiple external tools that I’ve intentionally exposed to Codex. For example, I have a custom CLI for uploading audio files, along with a skill that tells Codex how to use it. If I ask:

Upload these files via the CLI.

Codex chooses the correct tool, but the Auto Reviewer blocks it.

I’ve also had the Auto Reviewer block pushes to the GitHub origin configured for the repository and the creation of Linear issues.

The Auto Reviewer appears to be blocking legitimate tool invocations that are explicitly requested by the user, making it difficult to build reliable workflows around external tools.