Classic confinement request for: codex

store-requests classic-confinement
1
  • 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

2

This request has been added to the queue for review by the @reviewers team.

3

Hey @nysasounds

Whether the snap fits in the supported categories would require further discussion. Before that, classic confinement is a sensitive matter, and requires publisher vetting. To be able to proceed with publisher vetting, you need to be part of the `codex` upstream project or a trusted group (i.e. snapcrafters). As per the information you provided I think you don’t meet this criteria (please correct me if I’m wrong), and we cannot proceed with this request.

Thanks for your understanding

4

I second @jslarraz . In order to get classic confinement you need to be vetted. For now the work around would be to add the native tools to stage-packages or use connect for snap based packages like docker.

5

Thanks both @jslarraz and @pfsmorigo

It’s easy enough to add support for something like docker. That’s certainly true.

Sadly, stage-packages will never cover all the use cases, and so will always leave the snap of codex less compelling to use. This is to support development in any conceivable language, and would often require using specific versions of relevant runtime or associated tooling. Taking one very specific example, golang, I can’t reasonably add every version of golang to his snap.

But, it’s much more than dependencies, it’s general systems access. By way of another example, I was working on a project with codex, and when codex came to try and run the test coverage to validate the changes [ test coverage that already existed in the project ] it wasn’t able to, because the tests used a hard coded path of /var/tmp for some elements, which was not accessible to codex.

My goal is only to make this available via snap, because I think that’s better than the other codex packaging solutions currently available for Linux.

To that end, I would gladly transfer the project to the appropriate maintainers to ensure that this snap has the classic confinement it needs to make it usable. I will try and raise it in the upstream project, offering them the snap name. If there’s not any traction, I could try approaching Snapcrafters.

Cheers,

Just

1 Like