Codex CLI & Codex Remote Control on Linux: Installation, Configuration and Remote Access 2026

OpenAI Codex is no longer confined to the browser or a single development environment. With the Codex CLI, the coding agent works directly in the Linux terminal, where it can examine existing projects, edit files, run commands, and automate development tasks.

Things get even more interesting with Codex Remote Control and the remote workflows now available. Codex can work on development machines and remote systems while tasks are followed, extended, or approved from another device.

That makes it a powerful tool especially for system administrators, Linux users, and developers who run their own servers. There is, however, one important distinction to make:

The Codex CLI on Linux and Codex Remote are two different components.

This is exactly where a lot of confusion currently comes from. In this guide we'll fully install the Codex CLI on Debian and Ubuntu, configure it securely, and then look at the different ways to bring a Linux machine or Linux server into a Codex remote workflow.

If you're new to the Codex CLI, plain installation and everyday use are covered in detail in Install and Use Codex CLI on Linux (Read article). This special feature builds on that article and focuses on secure configuration plus the remote and smartphone workflow.

What is the Codex CLI?

The Codex CLI is the terminal client for OpenAI Codex. Codex can work directly inside a local repository with it. The agent can inspect files, make changes, use local development tools, and run commands. The CLI also supports interactive sessions, code review, web search, MCP servers, plugins, skills, and automated calls via codex exec.

A typical invocation looks fairly unremarkable at first:

cd ~/projects/my-app
codex

But you're not just in an ordinary chat after that. Codex knows the current working directory and, depending on the permissions it's been given, can work directly with the files and tools inside it. That makes Codex especially interesting for software development, Linux administration, troubleshooting, code review, refactoring, tests, documentation, Git workflows, CI/CD, automation, server administration, and DevOps tasks.

Codex CLI vs. Codex Remote Control: what's the difference?

Before we start installing, we need to separate three terms.

1. Codex CLI

The CLI runs directly on the machine in question: Linux → Codex CLI → project files, Git, shell, compiler, tests, local tools. Codex works wherever the repository or infrastructure actually lives.

2. Codex Remote

Codex Remote is the interface used to follow and steer running Codex work from other devices. OpenAI describes capabilities including: starting tasks, watching tasks in progress, answering follow-up questions, approving commands, reviewing results, viewing diffs, switching models, and sending further instructions.

Files, credentials, permissions, and development tools stay on the machine that actually executes the work. Status is transmitted between authorized devices through a secure relay infrastructure.

3. codex remote-control

The Codex CLI also ships its own command: codex remote-control. The current OpenAI documentation, however, marks it as Experimental.

Available subcommands include codex remote-control (start Remote Control in the foreground), codex remote-control start (start the local Codex app server as a daemon with Remote Control enabled), codex remote-control stop (stop the daemon again), and codex remote-control pair (generate a short-lived pairing code).

That sounds like you could pair any Linux server directly with the ChatGPT app. It's currently not quite that simple.

Does Codex Remote Control work directly on Linux?

This is where the state of things in August 2026 really matters. OpenAI's official guide for the standard remote workflow currently lists macOS and Windows as the supported remote hosts. Smartphone setup starts in the ChatGPT desktop app there — explicitly not through the Codex CLI or an IDE extension.

In practice: Smartphone (Codex Remote) → Mac/Windows with ChatGPT Desktop → SSH → Linux server (Codex CLI). This is currently the documented, and genuinely useful, way to use Codex remotely with a Linux server.

At the same time, OpenAI documents the experimental CLI command codex remote-control, used by managed remote-control clients and SSH-based remote workflows. In other words: codex remote-control shouldn't currently be treated as automatically equivalent to the fully supported smartphone remote setup on Linux. Since this area is under active development, that could change.

Prerequisites for Codex on Linux

All we need is an up-to-date Linux system with internet access. This guide works for Debian, Ubuntu, Linux Mint, Proxmox-based development machines, virtual Linux servers, VPS, and dedicated development servers.

Start by updating the system:

sudo apt update
sudo apt upgrade -y

Useful baseline tools:

sudo apt install curl git openssh-client ca-certificates -y

For a server you'll access over SSH later, also install:

sudo apt install openssh-server -y

Then check:

systemctl status ssh

Install the Codex CLI on Linux

OpenAI now recommends a standalone installer for Linux:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

The same installer can later be used to update the CLI too. Then check that the command is available:

codex --version

If Codex isn't found right after installation, open a new shell or reload your profile first, e.g. with source ~/.bashrc or source ~/.profile. Then: which codex.

Updating Codex

The installer can be re-run for updates too:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex --version

Especially for areas like Remote Control, it's worth updating Codex regularly, since these parts are under active development right now.

Logging in to Codex on Linux

For local Codex work, OpenAI supports two basic authentication methods: signing in with ChatGPT, and authenticating with an OpenAI API key. Signing in with ChatGPT suits interactive use, while API-key authentication can be useful for certain automation and CI/CD scenarios.

Option 1: Sign in with ChatGPT

codex login

Codex then starts the authentication flow. Once signed in, you can check the status:

codex login status

Option 2: Sign in with an API key

The API key should never be stored as plain text in a command or copied into your shell history. Instead, for example:

export OPENAI_API_KEY="YOUR_API_KEY"
printenv OPENAI_API_KEY | codex login --with-api-key

OpenAI notes that with API-key authentication, usage is billed under regular API pricing, and some features that require a ChatGPT workspace may be limited.

Checking your login

codex login status

Signing out:

codex logout

Where does Codex store its configuration?

The central per-user configuration lives on Linux at ~/.codex/config.toml. Project-specific settings can also be stored inside a repository at .codex/config.toml. A system-wide Linux configuration can live at /etc/codex/config.toml.

OpenAI applies a priority order of command-line flags, project configuration, profiles, user configuration, system configuration, and finally the built-in defaults.

Configuring Codex securely on Linux

First, create the configuration directory:

mkdir -p ~/.codex
nano ~/.codex/config.toml

For most local development environments, this is a sensible starting configuration:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

cli_auth_credentials_store = "auto"

web_search = "cached"

This gives Codex enough room for ordinary development work without immediately granting unrestricted access to the whole system.

What does sandbox_mode mean?

The sandbox mode determines what Codex is allowed to do on the system. OpenAI distinguishes, among others, sandbox_mode = "read-only" (Codex can read files but not simply modify them), sandbox_mode = "workspace-write" (Codex can edit files within the workspace and run typical local commands), and sandbox_mode = "danger-full-access" (sandbox boundaries are lifted entirely).

For normal local automation, OpenAI recommends the combination of sandbox_mode = "workspace-write" with approval_policy = "on-request" rather than granting unrestricted full access.

Why danger-full-access is risky

This configuration:

sandbox_mode = "danger-full-access"
approval_policy = "never"

effectively means the agent may act without a sandbox and without asking first. On a disposable development container, that might occasionally be acceptable. On a production Linux server, it's a remarkably broad grant of trust — especially dangerous if the account in question can reach /etc, /var, /root, Docker, Kubernetes, databases, SSH keys, cloud credentials, production systems, or backups.

The better approach: don't give Codex more rights — instead, let Codex work inside a sensibly bounded environment.

Why the Linux sandbox is particularly interesting

On Linux, Codex's sandbox currently relies by default on Bubblewrap (bwrap) and seccomp, among other mechanisms. That means actions aren't limited only by the model's own instructions, but additionally constrained at the operating-system level. You can even test the active sandbox:

codex sandbox linux

That's particularly useful for administrators who want to verify exactly which boundaries are actually in effect.

A recommended Codex configuration for Linux

For a normal development server, I'd start with something like this:

approval_policy = "on-request"
approvals_reviewer = "user"

sandbox_mode = "workspace-write"

allow_login_shell = false

cli_auth_credentials_store = "auto"

web_search = "cached"

[sandbox_workspace_write]
network_access = false

The idea behind it: changes inside the project are allowed, actions outside the sandbox require approval, network access for executed processes is disabled by default, login shells are additionally restricted, and critical decisions stay with the user. OpenAI also describes workspace-write combined with on-request as a lower-risk configuration for local automation.

Open your first project with Codex

Now let's create or open a repository:

mkdir -p ~/projects
cd ~/projects
git clone https://example.com/my-project.git
cd my-project
codex

Inside the Codex CLI, several commands are available: /status shows the current configuration, /permissions shows or changes permissions, /model lets you pick a model, and /review starts a code review.

OpenAI also recommends using Git checkpoints before larger agent tasks so changes can be reliably rolled back.

Create an AGENTS.md

One of my most important recommendations for Codex is a project instruction file. Inside Codex, /init can create an AGENTS.md where you document project rules. For example:

# Project rules

- Never modify production systems automatically.
- Always check for a backup before database changes.
- Never store credentials in Git.
- Run tests before every Git commit.
- Don't change existing APIs without an explicit instruction.
- Don't make changes outside this repository.
- Draft a plan first before risky changes.

A file like this is enormously valuable, especially on larger projects.

Checking Codex Remote Control on Linux

After installation, you can check whether the current CLI includes Remote Control:

codex remote-control --help

You can start it directly with codex remote-control. The process then runs in the foreground.

Starting Codex Remote Control as a daemon

Alternatively:

codex remote-control start

You can stop the service again with:

codex remote-control stop

OpenAI explicitly describes this feature as experimental right now, so I wouldn't rely on it as critical infrastructure on production systems just yet.

Generating a pairing code

Once the Remote Control daemon is running, you can generate a short-lived pairing code:

codex remote-control pair

For scripts or automated processing, JSON output is also available:

codex remote-control pair --json

According to OpenAI, the JSON output includes pairingCode, manualPairingCode, environmentId, and expiresAt.

One thing still matters, though: the documented smartphone remote workflow is currently set up through the ChatGPT desktop app, not directly through the Linux Codex CLI.

The most sensible remote architecture for Linux today

For administrators, the following architecture is currently the most interesting: a smartphone running the ChatGPT app with Codex Remote connects through a secure relay to a Mac or Windows machine running the ChatGPT desktop app with Codex. From there, an SSH connection reaches the actual Linux server — Debian or Ubuntu — where the Codex CLI lives alongside Git and your projects.

That keeps the actual project on Linux the whole time. The Mac or Windows machine only acts as a remote gateway, or desktop host.

Preparing a Linux server for Codex Remote over SSH

On the Linux server:

sudo apt update
sudo apt install openssh-server git curl -y

Enable SSH:

sudo systemctl enable --now ssh
systemctl status ssh

Then install Codex and log in:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex login

This matters because the desktop app starts the Codex app server on the remote system when it connects to an SSH host. The codex command therefore needs to be available in the remote user's login shell PATH.

Use a dedicated user for Codex

For servers, I strongly recommend not working with Codex directly as root. Instead:

sudo adduser codex
sudo mkdir -p /srv/codex-projects
sudo chown codex:codex /srv/codex-projects

root keeps handling the system and services, while a separate codex user is responsible only for development projects. That lets us restrict the agent's rights significantly at the operating-system level already.

Set up an SSH key for the Codex server

On the client:

ssh-keygen -t ed25519

Copy the public key over:

ssh-copy-id codex@server.example.com

Then test it:

ssh codex@server.example.com

Passwordless access via SSH key is far more practical for this workflow than typing a password every time.

Create an SSH config entry

On the machine running the ChatGPT desktop app:

nano ~/.ssh/config

Example:

Host codex-dev
    HostName server.example.com
    User codex
    IdentityFile ~/.ssh/id_ed25519

Then:

ssh codex-dev

OpenAI relies on exactly these kinds of concrete SSH aliases to automatically detect remote hosts.

Add the Linux server to Codex

In the ChatGPT desktop app: Settings → Connections → SSH → Add. Then select the SSH host you just set up. From there, you can use a project directory such as /srv/codex-projects/my-app.

The Codex conversation then runs against the remote file system, the remote shell, the tools installed there, and the dependencies present on that host. OpenAI explicitly states that remote project chats can run commands and read or modify files on the remote host.

Now bring in the smartphone

Smartphone access is set up on the supported desktop host. In the ChatGPT desktop app: Settings → Connections → Control this Mac or PC → Set up / Add. A QR code appears, which you scan with your phone. Both devices need to be connected to the same ChatGPT account or workspace. After that, the host shows up under Remote in the ChatGPT app.

The result: steering Linux development from your smartphone

This unlocks an impressive workflow. Say you're away from your desk and discover a bug. From your phone, you start:

Analyze the error in the backend. First check the logs and the most recent Git changes. Don't make any changes yet — first explain to me what the most likely cause is.

Codex does the actual work on the Linux server. It might then prepare a fix. If an action needs approval, that can also be reviewed remotely. OpenAI explicitly describes Remote as a way to start tasks from your phone, track progress, approve actions, and review diffs and test results.

Security rule 1: no root

A common mistake with AI agents is running sudo codex. That's rarely a good idea on a server. Codex should only be able to reach the areas actually required for its task.

Security rule 2: separate production systems

A professional setup could look like this: Codex → Development → Tests → Git Commit → Staging → Review → Deployment → Production. Not: Codex → Production.

Remote Control in particular tempts you to approve tasks quickly from your phone. But an approval on your phone is, technically, still an approval for a real command on a real system.

Security rule 3: use Git

Before larger changes:

git status
git add .
git commit -m "Checkpoint before Codex changes"

Now let Codex work. Afterward:

git diff
git status

Only commit after reviewing.

Security rule 4: no public app servers

For remote systems, this also applies: don't expose the Codex app server directly on a public port. OpenAI recommends SSH or other secure network mechanisms for remote connections, and warns against deploying unauthenticated app-server transports on shared or public networks. For remote networks, VPN or mesh-networking solutions are preferred over a directly publicly reachable app server.

So, not: Internet → Port 4500 → Codex app server. Better: VPN/SSH → Linux server → Codex.

Securing credentials on Linux

OpenAI may store Codex login credentials at ~/.codex/auth.json, among other locations. This file contains sensitive authentication information and must be treated like a password. OpenAI also supports configuring a credential store via cli_auth_credentials_store. cli_auth_credentials_store = "auto" is a sensible choice, or — where the system supports it — cli_auth_credentials_store = "keyring".

Signing in on a headless Linux server without a browser

Servers often don't have a graphical browser available. OpenAI documents several options for this, including forwarding the local authentication port over SSH. From your local machine:

ssh -L 1455:localhost:1455 user@server

Inside that SSH session:

codex login

You can then complete the displayed login in your local browser. Alternatively, on trusted systems, an existing authentication cache can be transferred. Since auth.json contains access tokens, this file should never be stored in Git or shared without protection.

A typical Codex configuration for a development server

approval_policy = "on-request"
approvals_reviewer = "user"

sandbox_mode = "workspace-write"

allow_login_shell = false

cli_auth_credentials_store = "auto"

web_search = "cached"

[sandbox_workspace_write]
network_access = false

That gives us a reasonably controlled starting point.

Only allow network access when it's actually needed

Some projects need npm install, pip install, or, say, apt-cache. Executed processes may therefore need network access. Codex supports finer-grained network rules and permission profiles for this. OpenAI's general recommendation is to grant network access as narrowly as possible rather than giving the sandbox blanket access — particularly relevant when the repository contains unfamiliar or potentially manipulated content.

Never let Codex blindly run unfamiliar repositories

A repository isn't just source code. It can also contain an AGENTS.md, README, shell scripts, install scripts, package.json, Makefiles, CI configuration, or MCP configuration. A compromised project could try to steer an agent toward unwanted actions.

The classic principle applies to AI agents too: unfamiliar code is still unfamiliar code. Codex doesn't replace a security review.

Very practical uses for Codex Remote on Linux

Analyzing server logs

Analyze the errors from the last 30 minutes in the logs. Don't change anything yet. First give me: 1. the likely cause, 2. the affected service, 3. possible consequences, 4. a suggested fix.

Investigating Docker issues

Check the current Docker status and figure out why the backend container isn't starting. Don't delete any containers and don't change any volumes.

Analyzing systemd errors

Analyze the nginx.service unit. Use systemctl and journalctl. Don't change any configuration before you've explained the cause to me.

Reviewing Git changes

Analyze all changes since the last commit. Look for bugs, security issues, breaking changes, and missing tests.

Preparing a deployment

Check whether the current branch is ready for staging. Run the tests and review the configuration. Don't perform a deployment.

That last instruction really matters. An agent doesn't have to automatically carry out every possible step.

Can Codex Remote fully administer a Linux server?

Technically, Codex can carry out very far-reaching tasks with the permissions of the account it runs as. Whether Codex can, say, run systemctl restart nginx depends on the sandbox, the user's permissions, and the approvals in place. And if that user also has unrestricted sudo, that can quickly amount to practically full server access.

For professional environments, a restricted sudo configuration would be far more sensible. For example: Codex is allowed to run systemctl status, journalctl, and certain test scripts. Codex is not allowed to run userdel, rm on system directories, disable the firewall, change the SSH configuration, or delete production databases. The principle of least privilege matters even more with AI agents involved.

Codex Remote is not a replacement for SSH

Codex Remote shouldn't be seen as a replacement for classic administration. A better combination is SSH, Git, monitoring, backups, Codex, and approval rules. Codex is the intelligent assistant inside a controlled environment — not the security architecture itself.

Remote Control in businesses

Business and enterprise environments add further policy layers. OpenAI lets administrators restrict Remote Control through requirements or workspace policies. For example, the setting allow_remote_control = false can disable Remote Control for managed users. Sandbox modes and approval policies can also be enforced centrally. That matters especially when Codex is used against internal Git repositories, production code, customer data, company servers, or CI/CD systems.

Is Codex Remote Control on Linux production-ready yet?

A distinction matters here. The Codex CLI itself is a regular part of the Codex platform. The CLI command codex remote-control, however, is still listed as experimental in the current developer documentation. The regular Codex Remote workflow through the ChatGPT app is considerably more mature and supports remote tasks, approvals, and SSH-based development environments.

For a production Linux workflow, I'd currently favor: ChatGPT Desktop → SSH → Linux development server → Codex CLI, rather than exposing an experimental app server publicly.

My recommended architecture for administrators

For a small-to-medium development operation, a solid setup could look like this: Smartphone (ChatGPT Remote) → Admin workstation (ChatGPT Desktop) → SSH key → Linux dev server with a dedicated codex user, the Codex CLI, Git, and Docker, → test environment → staging → manual approval → production.

That combines the speed of a coding agent with classic security controls.

Common mistakes with Codex on Linux

codex: command not found

Check with which codex. Then start a new shell, or run source ~/.bashrc.

Login doesn't work on the server

On headless systems, forwarding the login callback port over SSH can help: ssh -L 1455:localhost:1455 user@server, then codex login.

The remote host can't be found

Check your SSH configuration with cat ~/.ssh/config, then ssh codex-dev. The host needs to be reachable with a plain OpenSSH client first.

Codex isn't in the PATH over SSH

Test with ssh codex-dev 'which codex'. You should get a valid path back. If nothing comes back, Codex isn't available in the remote user's login shell — exactly the requirement OpenAI states for SSH-based Codex projects.

Conclusion: the Codex CLI and Remote Control turn Linux into an AI workspace

With the Codex CLI, OpenAI Codex on Linux becomes far more than a chatbot. The agent can work directly with source code, Git, shell commands, tests, build systems, logs, and development tools.

Things get really interesting through the remote workflows, though. A Linux server can be connected to Codex over SSH, while tasks are then monitored, extended, and approved from a smartphone through a supported desktop host and the ChatGPT app.

For system administrators, that opens up entirely new possibilities. At the same time, responsibility grows too. Anyone giving an AI agent shell access should apply the same rules as with any other administrative tool: least privilege, Git, backups, sandboxing, separate development environments, and controlled approvals.

The most interesting development, then, probably isn't whether Codex can run even more commands. What matters is how safely we integrate AI agents into our real infrastructure.

To see how MCP handles connecting additional tools and data sources in a controlled way, read Model Context Protocol (MCP) Explained (Read article).

FAQ: Codex CLI and Remote Control on Linux

Does OpenAI Codex run on Linux?

Yes. The Codex CLI can be installed directly on Linux and works there in the terminal with local projects, Git, and existing development tools.

How do I install Codex CLI on Ubuntu?

With the official standalone installer: curl -fsSL https://chatgpt.com/codex/install.sh | sh

Does Codex CLI also work on Debian?

Yes. The Codex CLI runs on Linux and can be set up on a Debian system using the Linux installer.

Can I control Codex from my smartphone?

Codex Remote lets you start, follow, and approve Codex work through the ChatGPT app. The currently documented direct remote-host workflow uses the ChatGPT desktop app on macOS or Windows for this.

Can the actual project still live on Linux?

Yes. The ChatGPT desktop app can connect to a Linux host over SSH. Codex then works with that host's file system and shell.

What does codex remote-control do?

The command starts or manages the local Codex app server with remote-control enabled. OpenAI currently marks this CLI command as experimental.

How do I start Codex Remote Control?

In the foreground with codex remote-control, as a daemon with codex remote-control start, and stop it with codex remote-control stop.

How do I generate a pairing code?

With codex remote-control pair, or as JSON with codex remote-control pair --json.

Should Codex run as root?

For normal development and server tasks, Codex should ideally run under a separate user with the minimum permissions required.

Where is the Codex configuration stored?

Per-user at ~/.codex/config.toml, per-project at .codex/config.toml, and system-wide on Linux at /etc/codex/config.toml.

Which sandbox setting makes sense?

For normal development work, sandbox_mode = "workspace-write" combined with approval_policy = "on-request" is often a good fit. OpenAI lists this combination as a lower-risk configuration for local automation.

Sources and currency

Article date and fact-check: August 18, 2026. This article is based on the officially available OpenAI documentation on the Codex CLI, configuration, sandboxing, authentication, Remote Control, and SSH-based remote connections. In particular, codex remote-control is still marked experimental by OpenAI, and its feature set and supported platforms may change accordingly.