Codex in ChatGPT Linux Preview

OpenAI announced Codex in ChatGPT desktop app for Linux is now in preview, an official preview that brings its coding agent into the ChatGPT desktop app on Linux. It deals with a simple gap: many developers live on Linux, but the desktop ChatGPT surface had not been the obvious home for OpenAI Codex work there. The takeaway is calm: try it, but treat the desktop app as another entry point into Codex workflows, not as a reason to skip repo boundaries, AGENTS.md rules, or verification.

Codex is OpenAI’s coding agent for reading, editing, and reasoning about code with developer approval. For people already using the codex cli, this preview matters because it hints at a more continuous loop between chat, terminal work, and repo-scoped instructions.

Check what the preview actually changes

As of August 13, 2026, the concrete news is availability: Codex is now in preview inside the ChatGPT desktop app for Linux. That is enough to matter. Linux users often run their development environment, shell, editor, containers, and local services on the same machine.

The release does not turn the desktop app into a replacement for every terminal habit. It gives developers another place to start or continue Codex work. The trap is assuming that a desktop preview means the whole workflow is now settled.

One detail from the developer chatter was easy to miss. Some people saw OS-specific download behavior, where a Codex or ChatGPT page changed based on their current platform. If you are checking the preview from a different machine, do not over-read the landing page. Verify the Linux path directly from OpenAI’s own page.

Treat the app as an entry point, not a sandbox

The sharpest objection was about isolation. A desktop app can feel safer than a terminal command, but it still runs in your user environment unless you put boundaries around it. That matters when a coding agent can inspect a repo, propose edits, or connect to outside systems through tools.

The safest reading is simple: the preview improves access, not trust. Do not run the app with elevated privileges. Do not point it at secrets-heavy repos for the first test. Do not wire broad write-capable MCP servers into a casual experiment.

A useful MCP boundary note for a first pass looks like this:

MCP boundary for this repo:
- GitHub access is read-only unless a human opens the PR.
- Database access is disabled for desktop-agent experiments.
- The agent may read docs and tests, but must not edit secrets, CI tokens, or deployment config.

That note is boring on purpose. Good agent work starts with boring constraints.

Keep AGENTS.md as the repo contract

The desktop surface should not become a second memory system with different rules. If the repo already has AGENTS.md, keep using it. If it does not, add a small one before you ask Codex to touch code.

AGENTS.md is a repository instruction file that tells Codex how to work inside a codebase. It belongs near the code because the rules should travel with the work. A chat prompt is great for the current task. AGENTS.md is better for durable conventions.

Here is a small version for a TypeScript service:

# AGENTS.md

## Scope
These instructions apply to this repository.

## Before editing
- Read the failing test or issue first.
- Prefer the smallest change that fixes the behavior.
- Do not change public API names without calling it out.

## Verification
Run these before handing work back:
- npm test
- npm run lint
- git diff --check

## Safety
- Do not edit .env files, credentials, or deployment secrets.
- Ask before adding a new runtime dependency.

The trap is making AGENTS.md huge. Codex needs crisp rules more than a constitution. Start with scope, verification, and the files it must not touch.

For a deeper terminal-first pattern, this belongs with broader Codex CLI workflows, where the main habit is the same: give the agent a narrow job, then verify in the repo.

Ask what the desktop app replaces

A fair question from developers was: if the app is built with web technology, what is different from using ChatGPT in the browser? That is the right level of skepticism. A desktop app is only meaningfully different when it improves local workflow, file context, notifications, authentication, or handoff between chat and development tools.

For now, treat the Linux preview as a convenience layer around Codex work. It may be a nicer place to discuss a change, review a plan, or move between ChatGPT and coding tasks. It should not replace your shell, test runner, or code review.

A good pattern is desktop for intent, terminal for proof. Ask Codex to explain the change it wants to make. Then use your normal verification loop outside the app.

npm test
npm run lint
git diff --check
git status --short

That loop also pairs well with agent watchers and terminal multiplexing. We covered a neighboring idea in tmux-agent-switcher Watches Coding Agents, where the practical problem is keeping eyes on multiple agent sessions without losing control.

Try it safely in one repo

Use one boring repo first. Pick a service with tests, no production secrets, and a small issue you already understand. The goal is not to prove Codex can do magic. The goal is to see whether the ChatGPT desktop app makes the Codex loop smoother on Linux.

Copy this checklist into the issue or PR description:

## Codex desktop Linux preview checklist

Repo: ____________________
Task: ____________________
Branch: codex-linux-preview-________

Before starting:
- [ ] Repo has an AGENTS.md with scope, verification, and safety notes.
- [ ] No secrets, tokens, or production .env files are needed for this task.
- [ ] MCP tools are disabled or read-only for the first run.
- [ ] The task can be verified with local commands.

Ask Codex:
- [ ] Summarize the relevant files before editing.
- [ ] Propose the smallest change.
- [ ] Call out any dependency, API, or migration risk.

Verify outside the app:
- [ ] Run the repo test command.
- [ ] Run the repo lint or typecheck command.
- [ ] Review git diff manually.
- [ ] Revert anything unrelated to the task.

Handoff note:
- [ ] What changed?
- [ ] What was not changed?
- [ ] Which commands passed?
- [ ] What should a human review closely?

The important bit is the handoff note. It turns the preview from “a new place to click” into a reproducible Codex workflow.

Common questions

• Does this replace the Codex CLI?

  No. The Linux desktop preview gives Codex another surface, but the codex cli still fits terminal-native work, scripted verification, and repo-local habits. A practical split is desktop for planning and review, CLI or shell for commands, tests, and exact diffs.

• Is the desktop app safer than running an agent in the terminal?

  Not by default. A desktop app can still act with the permissions of your user account, and connected tools can widen that reach. For the first repo, avoid admin privileges, keep MCP read-only, and choose a codebase where secrets are not required.

• What is different from using ChatGPT in a browser?

  The difference should be workflow convenience, not assumed intelligence or security. A desktop app can make local context and repeated coding sessions feel smoother, but the preview announcement alone does not prove stronger isolation. Judge it by the loop: context in, edits out, tests run, diff reviewed.

• Why did some people see a Windows download page?

  Some OpenAI pages may adapt downloads based on the operating system you are using. That can confuse quick checks from another machine or browser session. If you are validating Linux availability, start from OpenAI’s announcement and product docs rather than a cached or OS-detected landing page.

• What should I try first?

  Try a small tested change in one existing repo. Good first tasks include fixing a failing unit test, updating a narrow helper, or improving an error message. Avoid auth, billing, migrations, deployment config, and anything that requires production credentials.

Best ways to use this research

• Best for: Linux developers who already use ChatGPT or Codex and want to know whether the desktop preview changes their day-to-day coding loop.
• Best first artifact: A short AGENTS.md file with verification commands and safety boundaries. It gives Codex the repo contract before any prompt gets clever.
• Best comparison angle: Compare desktop, browser, and codex cli by where proof happens. The best surface is the one that gets you to a reviewed diff and passing tests with the least confusion.
• Best safety habit: Keep the first run read-only where possible. If tools need write access, limit them to the repo and review every file change before committing.

Further reading

• OpenAI Developers — Codex quickstart
• OpenAI Developers — Codex CLI
• Codex in ChatGPT desktop app for Linux is now in preview — source

Next step

Install the preview only for a low-risk repo first, then run one small Codex task end to end. Keep the proof outside the chat: tests, lint, diff, and a short handoff note.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.