# OpenAI Codex Desktop Linux Install Guide [2026]: Sandbox + Data Egress > A Linux-first install + hardening checklist for Codex Desktop: verify downloads, sandbox the app, isolate SSH keys, route egress through a proxy, and prove what data leaves your machine. - Canonical: https://www.kunalganglani.com/blog/codex-desktop-linux-install-guide - Author: Kunal Ganglani - Published: 2026-08-13 · Updated: 2026-08-13 - Category: Developer Tools · Tags: linux, codex, ai-coding, desktop-app, security ## TL;DR Codex Desktop on Linux is an AI app that can read files you allow, run tools, and send requests over the internet. That makes install and security decisions matter more than the UI. The safest setup is simple: download from a trusted source, verify it if you can, run it in a sandbox, and only give it access to one workspace folder. If you care about company code, route its traffic through a proxy so you can control and log where it connects. Don’t guess what it uploads. Confirm it by watching network traffic during real tasks. ## OpenAI Codex Desktop Linux Install Guide [2026]: Sandbox + Data Egress Codex Desktop for Linux is the newest “AI coding agent on your machine” entry to hit the mainstream developer feed, and the search query I keep seeing is basically: **openai codex desktop linux install guide**. Most posts stop at “it exists.” That’s useless. On Linux, the only parts that matter are packaging trust, sandboxing, and what leaves your network. ![Computer screen displaying lines of code](https://cdn.sanity.io/images/vzekdneq/production/3cdfb5b5af75f075ecfc3ba5b203375411e44971-1200x675.webp) **Key takeaways** - Codex Desktop is a desktop agent running under your user account. Treat it like a powerful tool runner, not a cute chat UI. - On Linux, the safest default is boring: verify the download, sandbox it, and keep filesystem access scoped to a single workspace directory. - Assume anything you paste, any file you grant access to, and any command output you share can be uploaded. Don’t debate it. Measure it. - Put a proxy in front of it if you care about enterprise controls. You want one choke point for egress and audit. - If you can’t answer “what did it execute, what files did it read, and where did it connect,” you’re not operating it safely. > A desktop coding agent is not “just another app.” It’s automation with network access running in your user context. _(Inline illustration suggestion: a diagram showing “Codex Desktop → sandbox → workspace dir only → proxy → OpenAI/OpenRouter” with logs captured at each step.)_ ## Quickstart (the safe version) Linux desktop distribution still isn’t “solved.” Pretending otherwise is how people end up running unsigned binaries out of `~/Downloads` with their entire home directory mounted. Your job here is simple: reduce blast radius. ![laptop compute displaying command prompt](https://cdn.sanity.io/images/vzekdneq/production/b19c73fb374643143b456af87f43b22dfd7433da-1200x675.webp) ### Install in 7 steps (works regardless of distro/package) 1. **Download from an official source** (vendor site or official GitHub release). Avoid random repackaged builds. 1. **Verify integrity**: if checksums/signatures are provided, verify them before you run anything. 1. **Create a dedicated workspace directory** (example: `~/codex-work/`) and keep it boring. 1. **Create a dedicated OS user** if you’re serious (example: `codex`) so the agent doesn’t inherit your whole home directory. 1. **Start with a sandbox**: Flatpak permissions, Firejail, or a VM. Pick the lightest thing that gives you control. 1. **Start with network visibility**: run with a proxy or at least capture traffic during first run. 1. **Only then sign in** and connect it to a repo with non-sensitive code first. The HN thread about “ChatGPT Desktop (Codex Desktop) for Linux” immediately devolved into packaging + permissions anxiety. Good. That’s the right instinct. Here’s the thread: HN item id=49281916. ## What is Codex Desktop (and why Linux changes the risk) Codex Desktop is a local desktop application that can chat about code, read files you allow, and run developer tools/commands on your machine. That combination is the whole story. It’s not “just generating text.” It’s interacting with your filesystem and toolchain. ![a computer screen with a program running on it](https://cdn.sanity.io/images/vzekdneq/production/eca5d20ec9db66c2b90878890d4aa1ba50bd157f-1200x675.webp) Linux changes the risk profile for two reasons: 1. **Distribution is fragmented.** You might get an AppImage, a `.deb`, an `.rpm`, Flatpak, Snap, or the cursed “curl pipe bash” approach (don’t). Each format has different update semantics and a different sandbox story. 1. **Linux gives you real knobs.** If you’re willing to do a bit of work, you can lock an app down hard. Most people just… don’t. Also, the ecosystem around “Codex” isn’t tiny. The official `openai/codex` repo shows **six figures of GitHub stars and five figures of forks** (high drift, but still a real adoption signal). Source: [openai/codex](https://github.com/openai/codex). ## Installing and running Codex CLI (official baseline) Even if you’re here for the Desktop app, you should know what OpenAI ships “in the open.” - The `openai/codex` repository is OpenAI-maintained and includes a `Quickstart` plus install/run instructions for a terminal-based Codex CLI. See: [openai/codex](https://github.com/openai/codex). Why do I care? Because the CLI repo is where you can sanity-check the **security policy** and how OpenAI frames safe operation. ### Security policy (read it, don’t skim) OpenAI’s `openai/codex` repo includes a `SECURITY.md` with explicit guidance and a pointer to safe operation boundaries. The raw file is here: [OpenAI SECURITY.md](https://raw.githubusercontent.com/openai/codex/main/SECURITY.md). One line Linux operators should pay attention to: it points to “Agent approvals & security” documentation and explicitly calls out sandboxing, approvals, and network controls as the intended boundary controls. ### Using Codex with your ChatGPT plan The CLI docs include a section titled “Using Codex with your ChatGPT plan” (in the repo navigation/headings). Entitlements change. Plans change. Blog posts rot. I’m not publishing a brittle matrix that’s wrong in 60 days. My stance is operational: auth is an event. If you authenticate the desktop agent with your main account, you just tied a local tool runner to your primary identity. Use the minimum privileges that still lets you do your job. _(Inline illustration suggestion: a “two identities” diagram: personal account vs work account, each with separate SSH keys + separate proxy policy.)_ ## How do I install OpenAI Codex Desktop on Linux? (package formats + verification) I can’t assume which packaging OpenAI is shipping the day you read this. The HN thread has people mad about AppImage, and other people mad about “system integration daemons.” Welcome to Linux. So here’s the install guidance that stays true even if the packaging changes. ### 1) Prefer a sandboxed distribution format when possible If there’s a Flatpak build, it’s usually the best default for desktop agents because you get: - Portal-mediated filesystem access - Easy permission inspection - Straightforward revocation If you must use AppImage or a native package, add your own sandboxing layer (Firejail/AppArmor/VM). Otherwise you’re trusting whatever it does in your user context. And yes, that includes reading your dotfiles. ### 2) Verify what you can actually verify Verification comes in tiers: - **Best:** vendor provides a signed release and you verify the signature chain. - **Good:** vendor provides checksums and you verify the hash matches. - **Bare minimum:** download over TLS from a first-party domain and keep the artifact. What not to do: treat “someone posted a mirror on a forum” as a supply chain. ### 3) Update strategy (don’t let auto-update surprise you) Auto-update is fine. Silent auto-update is not. If the app updates itself outside your package manager, you need at least two things: - A way to **observe version changes** (log it, even if it’s a local text file) - A way to **roll back** if it breaks your sandbox assumptions At Rise People, the big lesson from shipping SOC 2-oriented scaffolding tooling was that compliance baked into the workflow beats “we’ll review it later.” Treat desktop agent updates the same way. If you don’t know what version is running, you don’t have a system. You have vibes. ## Does Codex Desktop run in a sandbox on Linux? (and how to enforce one) People casually assume desktop apps are sandboxed now. On Linux, that’s only true if you installed it in a sandboxed container format (Flatpak/Snap) or you built a sandbox yourself. Here’s how I think about the options: - **Flatpak:** best balance for most engineers. Use portals + overrides. - **Firejail:** great for AppImage and random binaries. Fast to apply, decent defaults. - **AppArmor/SELinux:** powerful, but you need patience and you’ll fight policy. - **VM (or a disposable dev VM):** if you’re dealing with sensitive repos, this is the boring right answer. I wrote a deeper variant of the VM approach here: [AI agents](/pillars/ai-agents) and specifically [AI Agent Sandbox Linux VM [2026]: Safe Tool Use, No K8s](/blog/ai-agent-sandbox-linux-vm). ### Flatpak permissions: the portal model you should embrace If you’re on Flatpak, inspect and minimize: - Filesystem mounts (home, host, specific paths) - Device access - Network access (usually on) The key control is scope. Your goal is: the agent sees `~/codex-work/` and basically nothing else. ### Firejail profile: blunt instrument, still effective Firejail isn’t magic. But it’s a solid “make it annoying to escape” layer for AppImage-style installs. Your initial success criteria: - No access to `~/.ssh` unless you explicitly allow it - No access to `~/.gnupg` - No access to `~/.aws`, `~/.kube`, etc. - Read/write only within a workspace dir If you’re writing a team policy, Firejail is the quick win. ## What files can Codex Desktop read on my machine? The honest answer: **whatever your OS permissions and the app sandbox allow**. So stop debating what Codex “should” do and define your boundaries: - **Workspace-only:** the agent can read/write within a single project directory. - **Repo-only:** it can read the repo but not your home directory. - **Full home:** don’t do this unless you genuinely accept the risk. ### Credential hygiene (SSH, GPG, cloud creds) If the agent can read `~/.ssh`, it can often: - Enumerate keys - Use `ssh-agent` sockets if accessible - Perform git operations as you Hardening moves that actually work: - Use **separate SSH keys per repo or per trust domain** - Use a separate `SSH_AUTH_SOCK` for the agent environment - Put work keys on a hardware token if you can If you’re doing “vibe coding” with an agent that can see your production AWS creds in `~/.aws/credentials`, you’re not moving fast. You’re gambling. Related: AI security and [AI Agent Tool Use Security Attack Surface Checklist [2026]](/blog/ai-agent-tool-use-security-attack-surface-checklist-2026). ## Does Codex Desktop upload my code to OpenAI servers? (and how to reason about data egress) If the desktop agent is using a hosted model, **some data leaves your machine**. The interesting questions are: - exactly *what* leaves (full files vs diffs vs snippets) - when it leaves (on open vs on request) - whether telemetry/crash logs include code I prefer a test-driven posture: assume worst, then verify with network capture. ### “What data leaves your machine” table (practical threat model) | Data type | When it can be sent | How to limit it | How to verify | | --- | --- | --- | --- | | Prompts you type | Every request | Don’t paste secrets. Build redaction habits. | Capture HTTPS destinations + request sizes via proxy. | | Code snippets/diffs | When you ask it to edit/understand files | Restrict filesystem scope to workspace. | Compare file reads to outbound bursts. | | Terminal output | When you share command results | Don’t run commands that print secrets, then hand the output to the agent. | Log tool execution + capture outbound. | | Repo metadata (paths, filenames) | When agent indexes context | Limit directory access. Use a clean workspace dir. | Watch for directory listing activity + traffic spikes. | | Crash reports/telemetry | On crash or opt-in telemetry | Disable telemetry if possible; block endpoints. | Block domains; verify no egress to telemetry hosts. | This isn’t fear-mongering. It’s basic [LLM security](/glossary/llm) hygiene. ## How do I restrict Codex Desktop’s filesystem access? There are only three strategies that reliably work: 1. **Run it as a different Linux user** with a minimal home directory. 1. **Use a sandbox** (Flatpak portals or Firejail) and only mount the workspace. 1. **Use a VM** and treat it like a disposable coding environment. The “different user” approach is underrated because it’s boring and it works across distros. A policy I like for internal tools is default-deny, then grant access one directory at a time. At Rise People, our SOC 2 scaffolding CLI succeeded because the defaults nudged engineers into compliant paths instead of relying on PR reviews and good intentions. ## How do I set a proxy for Codex Desktop (HTTPS proxy)? If you want enterprise-style controls (audit, DLP, allowlists), you want a proxy choke point. Two patterns: - **System proxy:** set environment variables like `HTTPS_PROXY`/`HTTP_PROXY` for the app process (method varies by launch mechanism). - **Network-level enforcement:** firewall rules or an outbound tool like OpenSnitch. If you’re routing model traffic through a gateway, OpenRouter is a good mental model for “OpenAI-compatible” APIs. Their docs describe it as “hundreds of AI models through a single API endpoint,” and they show OpenAI-SDK integration as one path. See [OpenRouter docs](https://openrouter.ai/docs). I’m intentionally not claiming “all SDKs work by only swapping base URLs.” The tighter claim is: **many OpenAI SDKs can be configured to point at a different `base_url`, and OpenRouter documents OpenAI-SDK usage as one integration path.** ## How can I observe/confirm what network requests Codex Desktop makes? You have three practical options on Linux: - **Packet capture** (`tcpdump`/Wireshark): good for destinations, timing, volume. - **Explicit proxy** (mitmproxy or corporate proxy): best for audit and allowlists. - **Outbound firewall prompts** (OpenSnitch): best for interactive control. The goal isn’t to decrypt everything. It’s to answer three operator questions: - Which domains/IPs does it talk to? - How often? - How big are requests when it’s “reading” a repo? If your org is serious about [production AI](/pillars/ai-engineering-production), this is non-negotiable. _(Inline illustration suggestion: screenshot-style checklist “traffic capture on first run” with domains, timestamps, request sizes.)_ ## Where are Codex Desktop logs stored on Linux? (and what you should log yourself) Exact paths vary by packaging and build, so I’m not going to pretend there’s one canonical list. On Linux, desktop apps commonly write under: - `~/.config/…` - `~/.local/share/…` - `~/.cache/…` What matters more: keep your own minimal “paper trail,” regardless of where the app logs. A useful local audit trail for a desktop agent has three components: 1. **Process execution log** (what commands/tools did it run) 1. **Filesystem access boundaries** (what directories were even mounted/visible) 1. **Network egress record** (where did it connect) Incident writeups are basically endless proof that this matters. Tailscale’s August 12, 2026 post, “How we tracked down a 16-year-old SQLite bug,” is a love letter to forensics and traceability. They describe “months of intense forensics” to isolate a deep bug. Source: [Tailscale blog post](https://tailscale.com/blog/sqlite-wal-reset-bug). If you can’t reconstruct what happened, you don’t have a secure posture. You have a hope posture. For a deeper agent logging schema (OpenTelemetry + redaction), see: [AI Agent Observability Logging Schema [2026]: OTel + Redaction](/blog/ai-agent-observability-logging-schema-2026) and [OpenTelemetry Instrumentation for AI Agents [2026]: Ship It](/blog/opentelemetry-ai-agents-instrumentation). ## How do I disable telemetry/crash reporting in Codex Desktop? Treat telemetry control as a three-layer problem: 1. **In-app settings** (if offered) 1. **OS-level blocks** (hosts/firewall allowlists) 1. **Proxy policy** (best for teams) And even if you “disable telemetry,” validate it with your own traffic capture. Settings UIs lie all the time. Sometimes accidentally. Sometimes because nobody bothered to test the edge cases. ## Can I use separate SSH keys with Codex Desktop for Git operations? Yes. And you should. Two practical approaches: - **Per-repo SSH config:** map hostnames or repo paths to specific `IdentityFile` entries. - **Separate agent environment:** run Codex Desktop in an environment where `SSH_AUTH_SOCK` points to a restricted agent (or no agent at all). The point is simple: the agent shouldn’t inherit your keys to the kingdom. If it needs push access, give it a deploy key scoped to one repo. Not your personal key that can push everywhere. This ties directly to broader [AI agents](/pillars/ai-agents) hygiene and [AI Agent Threat Model: 7 Attack Vectors [2026]](/blog/ai-agent-threat-model-attack-surface). ## Team policy checklist (the minimum I’d ship) If you’re rolling Codex Desktop out to a team, here’s the baseline policy I’d want written down. - **Packaging:** only install from approved sources. Keep a record of version and artifact hash. - **Sandbox:** Flatpak or Firejail required. Workspace-only mounts. - **Credentials:** separate SSH keys. No shared tokens in env vars. No production AWS creds on dev boxes. - **Network:** proxy required for company repos. All egress logged. - **Observability:** log tool executions and keep logs for at least **30 days**. - **Human-in-the-loop:** anything that writes to git needs explicit approval, especially force pushes. If your agent can push to `main`, you’re one sloppy approval away from an incident. ## Closing: the prediction Linux is going to become the most controllable environment for agentic desktop tooling. Not because it’s “more secure by default,” but because it gives you knobs that actually work. My prediction for the next 12 months: the teams that win with Codex Desktop (or any desktop agent) won’t be the ones with the best prompts. They’ll be the ones who can answer, on demand, **what ran, what it touched, and what left the machine**. Photo by Xavier Cee on Unsplash. ## FAQ ### How do I install OpenAI Codex Desktop on Linux? Download it from an official source, verify any checksum/signature provided, and run it with a sandbox (Flatpak permissions, Firejail, or a VM). Start with a non-sensitive repo first. Then add proxying and logging before you connect it to real work code. ### Is Codex Desktop available for Ubuntu/Debian/Fedora? It depends on the packaging OpenAI ships at the time you install it. In practice, Ubuntu/Debian and Fedora users can usually run it via a universal format (like Flatpak or AppImage) or a native package (.deb/.rpm) if provided. Prefer a sandboxed format when you have the choice. ### Does Codex Desktop run in a sandbox on Linux? Not automatically. It’s sandboxed only if you install it in a sandboxed container format (like Flatpak/Snap) or you run it under a sandbox tool such as Firejail, AppArmor, SELinux policy, or a VM. If you installed it as a normal binary, it typically has normal user-level access. ### Does Codex Desktop upload my code to OpenAI servers? If it uses hosted models, some data you provide can be sent over the network, such as prompts, snippets, diffs, or tool output you share. The safest assumption is that anything you grant access to could be uploaded as context. You can confirm what’s happening by routing traffic through a proxy or capturing network destinations during real tasks. ### How do I set a proxy for Codex Desktop (HTTPS proxy)? Use either environment variables (like HTTPS proxy settings) when launching the app, or enforce routing at the network layer with firewall rules. For teams, a corporate proxy is the cleanest approach because it centralizes allowlists and audit logs. Always validate proxy usage by checking outbound connections during runtime. ### Can I use separate SSH keys with Codex Desktop for Git operations? Yes. Configure per-repo or per-host SSH identities so the app uses a limited key, not your main personal key. You can also run the app in an environment with a restricted SSH agent (or no agent) so it can’t silently reuse your existing credentials.