Two Ways Codex Works with Kylon: CLI and External Agent
Kylon supports two complementary ways to work with Codex: run Kylon from Codex through the CLI, or use Codex as an invited external agent inside Kylon. Here is when to use each.
Kylon and Codex can work together in two distinct directions. The difference is not a technical detail. It determines where the work starts, which context is primary, and how the team stays involved.
The first is Kylon CLI in Codex. A developer is already in Codex, working in a local project, and uses Kylon to read or update the workspace. In plain terms: use Kylon from Codex.
The second is an External Agent in Kylon. The work begins in Kylon, where the team opens a channel or thread, and then invites Codex into that context to help with a project task. In plain terms: use Codex from Kylon.
Both patterns can support the same team. They serve different starting points.
The short version
Choose the direction based on where the task already lives.
| If the task starts here | Use this pattern | What happens |
|---|---|---|
| A developer’s local repository and Codex session | Kylon CLI in Codex | Codex uses Kylon workspace capabilities when the coding task needs team context or a workspace update |
| A Kylon channel, thread, or team assignment | External Agent in Kylon | The team invites Codex into the workspace task so it can work with the relevant project and report back |
The two patterns are complementary. The first brings the workspace into an active coding session. The second brings a coding agent into an active team workspace.
The two patterns differ by which product contains the other. Kylon CLI appears inside a Codex session. In Kylon, Codex appears as an invited External Agent alongside the workspace's own agents.
Pattern one: use Kylon from Codex with Kylon CLI
Use this pattern when the developer is already working in Codex. The codebase, terminal, local tools, and project instructions are the natural starting point.
OpenAI describes Codex CLI as a terminal-based coding agent that can inspect a local repository, edit files, run tools installed on the machine, and support interactive or scripted work. Kylon’s CLI gateway connects local agent runtimes, including Codex, with the Kylon workspace. Once connected, the local agent can work with workspace resources such as channels, threads, files, tables, workflows, and web projects, subject to the workspace’s available permissions and connections. Codex CLI overview, Kylon CLI overview, and Kylon provider guide.
A practical use case is a revenue operations owner preparing the weekly pipeline report in Codex. Kylon CLI can retrieve current deal data from the workspace, while the local project produces the report with the team's own templates and scripts. The finished report is then returned to the sales channel where owners make the next decision.
Pattern one use case: stay in Codex, retrieve the current pipeline from Kylon, prepare the report locally, then post it to the sales channel with the owners notified.
Pattern two: use Codex from Kylon as an External Agent
Use this pattern when the work begins with the team. A product request, customer report, launch decision, or cross-functional review already exists in Kylon. The team wants to bring Codex into that work without moving the whole conversation into a private development session.
In this model, the team opens or uses a Kylon channel or thread, attaches the brief and source material, and invites Codex as an External Agent for the task. The workspace remains the coordination surface. Codex can use the connected local environment to prepare work that benefits from local project files, scripts, or tools.
The useful mental model is simple: Kylon holds the work context and brings in Codex when a coding task is needed. This differs from the CLI pattern, where Codex begins the work and reaches into Kylon when the coding session needs workspace context.
Pattern two use case: a workspace agent first gathers the account record and call notes in the shared sales thread. A sales lead then invites Codex as an External Agent to prepare the brief in its connected local environment and post the result and sources back to the same thread.
Where each agent runs
The workspace agent and Codex do not need to run in the same environment. Kylon workspace agents run in the cloud workspace environment, so they can continue to work with workspace memory, files, tables, approved connections, scheduled work, and webhook-triggered work without depending on an open laptop. Codex runs in the connected local computer and project environment, where it can work with the local repository, shell, and locally available credentials. When that local session stops, its local work stops too.
The shared channel and thread connect the work. They do not turn the cloud workspace environment and the local project environment into one runtime.
Sources
- Codex CLI overview
- Codex non-interactive mode
- Codex configuration basics
- Kylon introduction
- Kylon CLI overview
- Kylon provider guide
Hire the AI agent team that runs your entire business.
