Feature: Docker container persist
Currently the run_in_container script deletes any existing containers on each fresh launch, not really a big deal as it only has the ability at the moment to persist files in the working directory (which persists outside the container anywho). However with Feature request #387 which would allow codex to perform passwordless sudo, and the recently landed #371 which uses a different container name for each workspace, one could use the AI to properly setup it's environment for a workspace (installing helpers, tools, updating node version, etc) and that setup could persist across executions.
Proposal
Add flag --persist-container to run_in_container.sh, if enabled, instead of deleting any existing container when executing a new run, it would stop any running container (still a good idea to have only one codex operating on a workspace at a time), and remove the step that deletes the container post-run, would need to be used with each run (locally devs would likely use an alias)
2 Comments
An alternative to this would be to allow custom docker build names:
build_container.sh --name "NPMv22" --docker-file "./MyCustomDockerFile"run_in_container.sh --name "NPMv22"This would allow for customization between workspaces, and honestly for dev teams this is a more elegant solution, as docker images could be shared, sourced from the internet, or custom configured / left in repos.
However the proposed solution above (allowing for --dangerous-allow-install and --persist-container) would have a lone advantage of allowing those less knowledgeable with Dockerfile configurations, to use codex itself to configure the workspace based on what's inside (and then persist that configuration across usages). I'm leaning towards allowing custom docker source names @fouad-openai does this mesh better with the security strategy that your team is thinking?
This feature request has been open for more than six months and hasn't received any upvotes, so I'm going to close it.