Slack / Linear and SDK Integrations: Calling Codex Externally to Embed it in Your Products

📚 Series Navigation: The previous article [28 Non-Interactive Mode with codex exec] covered the "unattended" execution flow that accepts a prompt, runs a task, and exits—representing the first piece of piping Codex into scripts and CI. This article moves further outward: first, invoking Codex directly in Slack and Linear without opening terminals; second, using the official SDK and App Server to embed Codex as a component in your own programs and products. The next article [30 How to Choose a Model] returns to local environments, focusing on "which model to assign to a specific task."

ℹ️ This is an optional read for advanced users. If you only use Codex in terminals, desktop apps, or IDE extensions, you don't need this article yet, and skipping it won't affect subsequent steps. Return to it when you want to assign tasks directly in team chats or integrate Codex into your products.

Let's start with a real-world scenario to show what this article covers:

A colleague posts an error screenshot in a Slack channel, adding: "This login endpoint returned a 500 error again. Can anyone look?" Without opening my computer, I reply directly in the thread: @Codex check the 500 error above, and identify the cause in openai/our-backend. A few seconds later, Codex reacts with 👀 and replies: "Task started, please wait." I attend a meeting. When I return, Codex has posted the root cause and a diff patch in the thread, along with a link to open a PR.

In this flow, I did not write code, open a terminal, or touch my computer. This is "calling Codex externally"—liberating it from terminal windows and bringing it directly to the Slack and Linear workspaces your team uses daily. The SDK and App Server take it further: not just calling Codex in other apps, but embedding Codex inside your own products.

By reading this article, you will get:

• The two levels of calling Codex—integrating it with zero-code into Slack/Linear, vs. writing code to embed it in your programs
• Setup and usage details for calling @Codex in Slack, and how it selects environments and repositories automatically
• Assigning issues to Codex in Linear (via direct assignment or comments using @), and using triage rules to route issues automatically
• What the Codex SDK (TypeScript and Python) is, how to install it, its minimal code skeleton, and how it differs from codex exec
• What the App Server is, when to use it, and a guideline: "start with the SDK; do not jump straight to the App Server."
• A minimal SDK code example you can run and verify

⚠️ Specific commands, package names, configuration options, and default behaviors mentioned below are subject to the official Codex documentation (Slack / Linear / SDK / App Server); pricing plans and models are subject to your active installation.

---

01 Two Levels: Zero-Code Invocations vs. Programmatic Embedding

This article covers several items—Slack, Linear, the SDK, and the App Server. They handle two fundamentally different tasks. Let's clarify this first.

Analogy: Two ways to work with an assistant. The first way: the assistant is pre-configured in your daily office software (Slack, Linear), and you mention him in a channel to assign a task—Slack and Linear integrations are these entry points, built by OpenAI, requiring zero code and triggered via @ mentions. The second way: you want to hire the assistant to work in your own company, embedding him into your business workflows (writing code to call the SDK or App Server), making him a component of your product—this is the programmatic embedding path.

The division of labor across these four components:

Level	Component	Task	Environment
Zero-code invocation	Slack integration, Linear integration	Install integration, mention @Codex to assign tasks	OpenAI Cloud Task
Programmatic embedding	Codex SDK (TS / Python)	Write code to call and control Codex tasks	Your process / CI / server
Programmatic embedding (low-level)	App Server	Connect via JSON-RPC for deep client integration	Your client app / product

Keep this critical rule in mind: tasks sent via Slack and Linear run as Cloud Tasks (Codex Cloud, covered in Article 10). Simply put, when you mention @Codex in Slack, Codex launches a container in OpenAI's cloud, checks out your GitHub repository, runs the task, and returns the diff—the trigger changes to Slack messages, but the execution is identical. Thus, the prerequisites of Cloud Tasks (connecting GitHub, configuring environments, paid plans) apply to Slack and Linear integrations.

When do you need these integrations? Look for three indicators:

• "I want to assign this error check to Codex, but don't want to open my computer or terminal"—use Slack/Linear integrations.
• "I want to write a script to run a Codex workflow automatically in CI"—use the SDK.
• "I want to build a deep integration in my own product (like a custom VS Code extension) with message history, approvals, and event streams"—use the App Server.

💡 Summary in one sentence: This article splits integrations into two levels—Slack/Linear are pre-built zero-code entry points (running as Cloud Tasks), while the SDK/App Server are paths to embed Codex programmatically into your own products. Identify which level fits your needs before proceeding.

---

02 Calling Codex in Slack: @Codex Task Assignments

Let's look at the most accessible integration—Slack integration. Simply put: mention @Codex in a Slack channel or thread followed by a prompt, and it launches a cloud task and posts results back to the thread.

Analogy: Mentioning a teammate in a channel. You do not walk to a teammate's desk to ask a simple question—you mention them in a channel. They see it, handle the task, and reply in the channel. Codex acts as this teammate in Slack: you mention it with a prompt, it runs the task in the cloud, and replies in the thread. It reads the thread history, so you don't need to re-feed context.

Configuration Steps

Connecting Slack involves three steps (required to execute tasks):

1. Set up Cloud Tasks. This is the prerequisite—you must have a Plus, Pro, Business, Enterprise, or Edu plan (refer to the official ChatGPT pricing), a connected GitHub account, and at least one configured environment (environment). These match the Cloud Task configurations from Article 10.
2. Install the Slack App. Connect the Slack App in your Codex connectors settings. Note: Slack workspace policies may require administrator approvals before installation.
3. Add @Codex to channels. If it is not in the channel, Slack prompts you to add it when you mention the app.

Usage: Mentioning and Directing

Once configured, usage is simple:

1. Mention @Codex followed by your prompt in a channel or thread. It reads thread history to capture context automatically.
2. (Optional) Specify environments or repositories directly in your prompt, like: @Codex fix the above in openai/codex.
3. Wait for it to react with 👀 and post a task link; once finished, it returns results and (depending on settings) replies in the thread.

How It Selects Environments and Repositories

How does Codex know which repository to target if you don't specify it? The docs explain:

• Codex scans your accessible environments and selects the one that best matches your prompt; if the prompt is ambiguous, it falls back to your most recently used environment.
• Tasks run on the default branch of the first repository listed in the environment's repo map. To add repositories or change defaults, edit your repo map in Codex settings.
• If no matching environment or repository is found, Codex replies in Slack explaining what is missing.

Rather than letting it guess, be explicit. For teams managing multiple repositories, specify the target repository in the message (e.g., ...in openai/our-backend) to ensure it targets the correct code. Omitting it risks letting it target the wrong environment, resulting in incorrect responses.

Enterprise Data Controls: Hiding Task Details in Replies

This is important for enterprise security. By default, Codex replies in the thread on task completion, which can include code or configurations from the run environment. To block these details in Slack:

Enterprise administrators can uncheck "Allow Codex Slack app to post answers on task completion" in their ChatGPT workspace admin settings. Once disabled, Codex only posts the task link, keeping detailed outputs out of the thread.

The Slack integration workflow:

Diagram: Mentioning @Codex in Slack triggers a cloud task (creating a container, checking out the repo, running the agent), returning results back to the Slack thread and linking to the web console.

Hands-on: Testing Slack Invocations

Prerequisite: Slack workspace membership with app installation privileges (or admin assistance), a GitHub account connected to Codex, and at least one configured environment (Article 10 setup). Ensure network configurations allow connection to chatgpt.com.

Step 1: Install the app. Go to the connectors settings page, select Slack, and follow the authorization steps.

Expected: The Codex app appears in your Slack workspace.

Step 2: Add it to a channel. In a test channel, type @Codex and approve its addition to the channel.

Step 3: Assign a simple task (ensure instructions are clear and verifiable):

@Codex in openai/my-test-repo, add the line "Hello from Slack" to the top of the root README. Do not change other files.

Replace openai/my-test-repo with a repository you have write access to. Use a sandbox repo, not a production one.

Expected: Codex reacts with 👀, posts a task link, and returns the finished diff link in the thread. Seeing the diff and the option to open a PR confirms the setup is active. If it reports missing environments, verify your repo map settings.

💡 Summary in one sentence: Slack integration allows assigning tasks in channels/threads via @Codex mentions, executing cloud tasks, and returning results; prerequisites match Cloud Tasks (plan, GitHub link, environments), specify repositories explicitly to avoid ambiguity, and Enterprise admin rules can restrict detailed replies to links only.

---

03 Calling Codex in Linear: Routing Issues to Codex

Slack provides chat-triggered invocations, while Linear integration targets project management. When Linear (a project and ticket tracker) is connected to Codex, you can assign issues directly to Codex as you would to a developer.

Analogy: Assigning task cards on a kanban board. You assign cards to responsible team members, who work on tasks and post updates on the card. Codex acts as an assignable developer: you assign issues to it, it accepts them, runs tasks, posts updates on the card, and returns PR links.

This is available on paid plans. Enterprise plans require administrators to enable Cloud Tasks in workspace settings and toggle Codex for Linear in connector settings.

Configuration Steps

1. Set up Cloud Tasks: connect GitHub and create environments for your repositories in your Codex account.
2. Install Codex for Linear: enable it in the connectors page.
3. Link your Linear Account: type @Codex in a Linear issue comment box to authorize the connection.

Two Assignment Methods

The integration supports two paths:

Method 1: Assigning the issue directly. Assign the issue to Codex in the assignee selector. Codex accepts the issue, runs the task, and posts updates.

Method 2: Mentioning in comments. Type @Codex in the comments section to assign tasks or ask questions. It replies in the thread, allowing you to continue the conversation in the same session context.

Like Slack, Codex scans issue details to select the best environment and repository automatically. Specify the target repo explicitly in comments if needed, like: @Codex fix this in openai/codex.

Track progress in the issue's Activity feed or click the task link to view logs. Once complete, Codex posts a summary and a PR link to the issue.

Automated Routing: Triage Rules

You can route new incoming issues matching specific conditions to Codex automatically using triage rules:

1. Open Linear Settings.
2. Select your team under Your teams.
3. Enable Triage in workflow settings.
4. Create a rule under Triage rules, setting Delegate to Codex along with your filter conditions.

Incoming issues matching the rule assign to Codex automatically. Note this rule regarding usage credits: Codex executes tasks using the "issue creator's" account credentials—meaning credits are consumed from their account. Keep this in mind when configuring team rules.

Local Alternative: Linear MCP (For Local Codex Instances)

The Slack and Linear integrations above run Cloud Tasks. If you want your local Codex (Desktop App, CLI, or IDE extensions) to read Linear issues—like asking Codex in your terminal to "modify files based on issue ENG-123"—use the Linear MCP server (Article 20).

Connect it via the CLI:

codex mcp add linear --url https://mcp.linear.app/mcp

This prompts you to log in to Linear to authorize the connection. Alternatively, write the configuration to ~/.codex/config.toml:

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"

Run codex mcp login linear to authenticate. IDE extensions and the CLI share this configuration.

Do not confuse these paths: mentioning @Codex on Linear tickets runs Cloud Tasks; configuring the Linear MCP server allows local Codex instances to query Linear data. One is "Codex working in Linear," while the other is "local Codex reading Linear data."

Comparing "Cloud integrations":

Dimension	Slack Integration	Linear Integration
Invocation	@Codex in threads	Assigning issues / @Codex in comments
Automated Routing	—	Yes, via triage rules
Context Source	Thread history	Issue description + comments
Output Location	Posted in thread + task link	Posted in issue (Activity/comments) + task link
Execution	Cloud Task (spawns container, checks out repo)	Cloud Task
Local Alternative	—	Linear MCP (local Codex reads issue data)

My experience: Slack is suited for quick, ad-hoc tasks (checking errors on the fly), while Linear is suited for issues managed in ticket workflows—especially when combined with triage automation to let Codex write initial draft PRs for minor bugs, leaving developers to review code. This accelerates workflows.

💡 Summary in one sentence: Linear integration supports issue assignment and @Codex comment invocations, including automated triage routing (running on the issue creator's credentials); it runs as Cloud Tasks, and do not confuse it with Linear MCP which allows local Codex instances to read issue data.

---

04 Codex SDK: Embedding Codex Programmatically

We covered pre-built integration options; now let's explore programmatic embedding using the Codex SDK (software development kit to control Codex using code).

What problem does it solve? The codex exec command (Article 28) executes tasks in scripts, but controlling sessions, continuing multi-turn chats, and fetching structured outputs programmatically is difficult using raw shell commands. The SDK is built to address this. The official docs state:

The TypeScript library provides a way to control Codex within your application, offering more flexibility and control than non-interactive mode.

When should you use the SDK? The docs list four common scenarios:

• Integrating Codex into your CI/CD pipelines;
• Building autonomous agents that call Codex to run complex tasks;
• Embedding Codex into your internal tools and workflows;
• Integrating Codex into your applications.

Analogy: Moving from a remote control to the engine blueprints. codex exec is a remote control—triggering a run with fixed buttons. The SDK exposes the engine interfaces directly: you can write code to open a conversation thread, run a task, fetch results, continue the session on the same thread, or adjust sandbox permissions per turn—providing granular control in your code.

Supported Languages: TypeScript and Python

Codex provides SDKs for both environments. Note these differences:

	TypeScript	Python
Installation	npm install @openai/codex-sdk	pip install openai-codex
Prerequisite	Node.js 18+	Python 3.10+
Target Scope	Server-side (server-side)	Local app-server controller
Mechanism	Server-side execution	Controls the local Codex app-server via JSON-RPC
Maturity	Stable	Beta

Key details:

• TypeScript SDK runs on the server side and requires Node.js 18+. Do not run it in browsers.
• The Python SDK is in beta and has specific naming. The package name is openai-codex, not codex-sdk. The library bundles a specific version of the Codex CLI runtime—the system manages this automatically, but you can point it to a specific local CLI binary using CodexConfig(codex_bin=...).

A naming detail: the TS package is @openai/codex-sdk, while the Python package is openai-codex. Use the correct name for your environment.

Minimal Code Skeletons

TypeScript—open a thread, run a prompt, and output the result:

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();
const result = await thread.run(
  "Make a plan to diagnose and fix the CI failures"
);

console.log(result);

To continue the session, run another step on the same thread object, or restore a past thread by ID:

// Continue on the same thread
const result = await thread.run("Implement the plan");
console.log(result);

// Restore a past thread by ID
const threadId = "<thread-id>";
const thread2 = codex.resumeThread(threadId);
const result2 = await thread2.run("Pick up where you left off");
console.log(result2);

Python—similar structure, using context managers to handle execution scopes:

from openai_codex import Codex, Sandbox

with Codex() as codex:
    thread = codex.thread_start(
        model="gpt-5.4",
        sandbox=Sandbox.workspace_write,
    )
    result = thread.run("Make a plan to diagnose and fix the CI failures")
    print(result.final_response)

The model gpt-5.4 is illustrative; use active models on your account.

For asynchronous applications, use AsyncCodex:

import asyncio
from openai_codex import AsyncCodex

async def main() -> None:
    async with AsyncCodex() as codex:
        thread = await codex.thread_start(model="gpt-5.4")
        result = await thread.run("Implement the plan")
        print(result.final_response)

asyncio.run(main())

Sandbox Configurations

Matching CLI settings (Article 15), the Python SDK uses Sandbox presets to configure file permissions. You can set them on thread creation or adjust them for specific turns:

from openai_codex import Codex, Sandbox

with Codex() as codex:
    thread = codex.thread_start(sandbox=Sandbox.workspace_write)
    thread.run("Make the requested change.")
    # restrict write access in the review turn
    review = thread.run("Review the diff only.", sandbox=Sandbox.read_only)

The three presets:

Preset	Permissions
Sandbox.read_only	Reads files, blocks write actions
Sandbox.workspace_write	Reads files, allows writes inside the workspace
Sandbox.full_access	Unrestricted file system access

Default behavior: if sandbox is omitted, the SDK uses the defaults configured on the app-server. Once a sandbox level is set on a turn using run(...), it persists for subsequent turns in that thread unless explicitly changed.

SDK vs. codex exec

How does the SDK differ from codex exec (Article 28)? Simply: exec runs one-off commands and outputs text, while the SDK manages ongoing session threads, multi-turn prompts, and changes sandbox levels programmatically.

Dimension	codex exec (Article 28)	Codex SDK
Form	CLI Utility	Code Library
Usage	Executing terminal commands	Importing and calling in code
Continuity	Requires resume parameters	Maintained via thread objects and run()
Results	Parsing stdout or JSONL streams	Reading response object variables (e.g., final_response)
Sandbox	CLI Flags	Code presets, adjustable per turn
Best For	Lightweight, one-off automated tasks	Custom applications, autonomous agents, product integrations

Rule of thumb: to run checkups in scripts and output results, use codex exec; to manage chat threads, evaluate steps, or build custom tools in code, use the SDK.

💡 Summary in one sentence: The Codex SDK allows starting threads, running multi-turn prompts, and managing sandbox levels in code—supporting TypeScript (@openai/codex-sdk on Node 18+ servers) and Python (openai-codex in beta, controlling the local app-server); offering finer control than codex exec.

---

05 App Server: Deep Product Integrations

We conclude with the lowest-level component—the App Server. The rule: the App Server provides the interfaces that power rich client integrations (like the official VS Code extension), and is used when you want to build custom IDE integrations or GUI clients.

It provides connections for authentication, message history, approvals, and agent event streams—the exact components needed to build custom client UIs.

Analogy: The SDK is an assembled engine; the App Server is the raw terminal block. Most developers need an engine they can start and query (the SDK). If you are building a custom car, you need the terminal block to connect indicators, indicators, and dials (session logs, approval prompts, events). The App Server exposes Codex's internals via JSON-RPC to allow you to build custom client UIs.

Technically, it functions like MCP—using JSON-RPC 2.0 messages for bi-directional communication over standard input/output (stdio). Launch it via:

codex app-server

Its core concepts align with our previous articles:

• Thread (thread): A conversation history containing turns;
• Turn (turn): A user prompt and the subsequent agent execution steps;
• Item (item): Input/output events (user message, agent message, commands, file edits, tool runs).

The lifecycle: initialize connection → start/resume a thread → run a turn → parse streaming events (items started/finished, text increments, tool logs) → turn completion. You must parse these JSON-RPC exchanges yourself—making it complex to implement.

When do you choose the App Server vs. the SDK? The official documentation sets a clear boundary:

If you are running Codex in CI or for automated tasks, use the Codex SDK, not the App Server.

The boundary:

Task	Component
Automating tasks, CI, writing calling scripts	SDK
Building agents to run tasks	SDK
Building custom IDE extensions or GUI clients (requiring history, approvals, event logs)	App Server

For most users: use the SDK and skip the App Server. The App Server is built for product teams building rich IDE extensions or GUI tools. Do not start with the App Server; it adds unnecessary complexity. Build workflows using the SDK first.

The App Server is open-source (available in the Codex GitHub repository), but digging into its source code represents a different scope of work.

💡 Summary in one sentence: The App Server is Codex's low-level JSON-RPC interface designed for custom rich clients (like IDE extensions); the docs state: use the SDK for CI and automated tasks, not the App Server; skip the App Server unless building client products.

---

06 Hands-on: Running a Minimal SDK Script

Let's run a minimal Codex SDK script—reading a local file and outputting a summary. We use TypeScript (which runs on the server side).

Prerequisite: Node.js 18+ (node -v prints version details), and Codex CLI installed and authenticated (codex login, Article 03). The SDK connects to API services; verify network connections.

Step 1: Initialize a project directory

mkdir codex-sdk-demo
cd codex-sdk-demo
npm init -y

Step 2: Install the SDK

npm install @openai/codex-sdk

Expected: npm reports packages added, and @openai/codex-sdk appears in node_modules.

Step 3: Create a test file

Create a file named hello.txt with some text:

This project is a tiny demo for the Codex SDK.

Step 4: Write the calling script

Create run.mjs (using .mjs to support top-level await):

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();
const result = await thread.run(
  "Read hello.txt in the current directory and summarize it in one sentence."
);

console.log(result);

This instantiates Codex, starts a thread, runs the prompt, and logs the response.

Step 5: Execute the script

node run.mjs

Expected: The script runs, and prints the summary of hello.txt returned by Codex. This verifies the SDK connection. If authentication errors occur, verify your codex login status.

This verifies the flow: installing the SDK → starting a thread → running a prompt → logging results. Build on this setup to add multi-turn runs or adjust sandbox levels.

💡 Summary in one sentence: The hands-on workflow has five steps—initialize directory → install @openai/codex-sdk → create a test file → write a thread-run script → execute with Node; verifying the programmatic connection.

---

07 Selecting the Right Tool

To help you choose the correct tool:

Need	Tool	Why
Assign tasks to Codex in team chats	Slack Integration	Zero-code, uses @ mentions
Assign issues automatically in ticket trackers	Linear Integration	Zero-code, supports triage routing
Query Linear issues in local Codex sessions	Linear MCP	Local MCP query tool, not remote assignment
Run automated checks in simple scripts / CI	codex exec (Article 28)	Lightweight CLI utility
Control sessions, multi-turn prompts in code	Codex SDK	Programmatic library, manages threads and sandbox levels
Build IDE extensions or GUI clients	App Server	Low-level JSON-RPC streams for UI integrations

Consider these rules:

• Do not use the SDK if exec can handle the task. If you only need to run a check in CI and output results, use codex exec (with --json if needed). Prefer lightweight tools for simple needs.
• Do not use the App Server if the SDK can handle the task. Setting up JSON-RPC exchanges manually adds unnecessary complexity.
• Slack/Linear integrations and SDK/App Server are different scopes. The former are zero-code external invocations; the latter are programmatic embedding options. You can use both concurrently.

I use Slack mentions daily for convenience, write codex exec in CI scripts, and use the SDK for custom background helpers. I have not needed the App Server—it is built for product teams. Start with zero-code integrations and lightweight CLI calls, and move to the SDK when you need programmatic thread control.

💡 Summary in one sentence: Use Slack/Linear for chat invocations, Linear MCP for local issue queries, exec for scripting, the SDK for programmatic session control, and the App Server for IDE/GUI client products. Match tools to task complexity.

---

08 Summary

We have explored calling Codex externally and embedding it programmatically—integrating it into Slack, Linear, custom code scripts, and client interfaces.

Let's review the key components:

Tool	Invocation	Key Takeaway
Slack	@Codex in threads	Runs as a Cloud Task; matches settings from Article 10
Linear	Assigning issues / @Codex comments	Supports triage routing, running on issue creator credentials
Linear MCP	Local MCP server	Exposes issue data to local Codex instances
SDK	Code library	TypeScript (@openai/codex-sdk) and Python (openai-codex); manages threads and sandboxes
SDK vs. exec	Programmatic library vs. CLI	exec runs one-off tasks; SDK manages multi-turn sessions and sandboxes
App Server	JSON-RPC Interface	Built for rich clients (IDE extensions); do not use in CI

You should now be able to: choose between zero-code invocations and programmatic embedding; assign tasks in Slack and Linear (understanding environment matching and triage rules); connect Linear MCP; configure TypeScript and Python SDKs; and understand when to use the App Server.

Codex can now be integrated into chats, trackers, scripts, and applications.

---

The next article [30 How to Choose a Model]—whether you call Codex in Slack or via the SDK, a key question remains: which model should run the task? We have used model parameters in templates, but we have not discussed how to choose. The next article covers: analyzing model profiles, matching tasks to models, and balancing speed, cost, and accuracy.

---

Recommended Reading

• Managing External Tools with MCP: Adding Connections to Codex
• Git and GitHub Integration: Let Codex Act as a Reviewer in Your PRs
• In-Depth Guide to config.toml: Managing All Settings in One File