Codex's integrations with Slack and Linear give the agent task context beyond the local repository: to start work right from a discussion or continue it from an issue. This is convenient, but it is important to understand their boundary at once. They do not replace recipient and project resolution and require separate service authorization. An external integration is another trust surface, not a magic channel through which Codex automatically sees and can do everything visible to a human in Slack or Linear.
A key misconception is worth dispelling at once: visibility to a human is not equal to visibility to Codex. A public link or an issue title does not guarantee that Codex sees the private content. For the integration to actually have access, the connector or app must be installed, authorized and allowed by the workspace policy. Hence a frequent mistake - throwing the agent a link and expecting it to "read the thread", while without an installed and authorized connector it sees nothing beyond what is explicitly available to it.
It helps to gather the integrations into a table by typical scenario and what to check once. Below is the map: Slack to start a task from a discussion with a return of progress and result, Linear to create or continue a task from an issue. You return to this map when connecting an external trigger: each integration has its own workflow and its own list of what needs checking before relying on it in a real process.
What exactly is checked is a concrete question. For Slack it is channel visibility, the linked repository, identity and the presence of sensitive context in the discussion. For Linear - the workspace, the team and the way the issue maps to the work. Each of these points is a potential source of error: the wrong repository, the wrong team, private data in a thread that should not be dragged into the task. They are checked in advance, not after the agent has already started acting on the wrong context.
| Integration | Typical workflow | What to check |
|---|---|---|
| Slack | Start a task from a discussion, return progress/result | Channel visibility, linked repository, identity, sensitive context |
| Linear | Create or continue a task from an issue |
| Workspace, team, mapping of the issue to the work |
Identity in such integrations is a separate topic that must not be missed. On whose behalf the task is started and whose rights apply determines what is available to the agent and what a specific person is responsible for. Mixing identities in a shared channel is dangerous: a task started by one must not silently act with another's rights. So identity is checked the same as access: who triggers, with what authority, and whether it goes beyond what this person is entitled to initiate.
External mutation is the most sensitive thing these integrations give, and it is approached carefully. Creating or changing an issue, sending a message, changing a task's state are actions with consequences in an external system, not harmless reading. They are subject to the same principles as any side-effecting action: confirmation where needed, narrow rights, clarity about what exactly and on whose behalf is changed. Safe external mutation is a consciously granted narrow right, not a side effect of a convenient integration.
The point of the Slack and Linear integrations is to fit Codex into the team's real workflow, not to create a bypass channel. Starting a task from the discussion where it arose and returning the result there is cheap and convenient. But convenience does not remove boundaries: service authorization, checking context and identity, caution with external mutation. An integration is useful exactly to the extent you understand what it actually sees, on whose behalf it acts and what it can change externally.
The typical failures around Slack and Linear are predictable. Throwing a link and expecting access without an installed and authorized connector. Not checking the linked repository or team and starting work on the wrong context. Missing sensitive data in a thread that should not have been dragged into the task. And allowing external mutation without a consciously granted narrow right and an identity check. Authorize the service explicitly, check the context and identity and treat external mutation as a side-effecting action.