- name: codex
- description: Codex is a local AI coding agent that operates as a terminal-based IDE. It inspects repositories, generates and edits code, and runs system commands to test, debug, and validate its changes in real-time. Codex utilises Bubblewrap internally to securely sandbox the execution of AI-generated code and arbitrary build tools.
- snapcraft: codex/snap/snapcraft.yaml at classic · nysasounds/codex · GitHub
- upstream: GitHub - openai/codex: Lightweight coding agent that runs in your terminal · GitHub
- upstream-relation: No direct relation
- supported-category:
- IDE
- tools for local, non-root user driven configuration of/switching to development workspaces/environments
- reasoning: The Codex app operates as an autonomous/prompted, AI-driven IDE. Its core workflow consists of reading project files, authoring code, and then executing arbitrary host tools to validate those changes for potentially any veriety of code.
Under strict confinement, Codex cannot function properly as an IDE for two primary reasons:
Execution of Arbitrary Host Toolchains [ non-root user ]
Like any traditional IDE, Codex requires full access to the user’s native development environment. It needs to trigger the user’s existing host toolchains—such as git, npm, gcc, go, or docker—to compile projects and run test suites.
Strictly confined snaps cannot execute unconfined binaries on the host system.
Because Codex adapts to whatever codebase the user is working on, it is impossible to bundle every potential language compiler or runtime inside the snap. Classic confinement is required to provide standard IDE-level access to the host environment, and make it usable across any potential supported use cases.
Conflict with Internal Bubblewrap Sandboxing
Because Codex acts as an automated IDE, it frequently executes untrusted, AI-generated code. To protect the user’s host system, Codex relies heavily on Bubblewrap (bwrap) to create its own internal, context-aware sandboxes before compiling or running code. It directly prompts the user to ask about the trust of the current directory before working in it, and also to ask for permissions when accessing anything outside of that directory [ to run a command, for example ].
As strictly confined snaps utilise AppArmor, seccomp, and namespaces, it can interfere with Bubblewrap in various ways. This “nesting” of sandboxes also adds considerable complexity.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
I did initially try and make this strictly confined, but it’s fairly quickly become clear that it’s not really sustainable without diminishing the usability of the application.
My intention here is make the Codex CLI available for installation “natively”, rather than current alternative on Linux which is NPM.
Who am I ?
I’m a community member/enthusiast that creates snaps where I see a gap. For the last few years I’ve also maintain a strictly confined alternative to the AWS CLI snap. I initially created it to fill the gap before AWS decided to finally package v2, but kept it going as a confined alternative to the AWS classic version.
I look forward to your feedback.
Thanks!
Cheers,
Just