-
Notifications
You must be signed in to change notification settings - Fork 2.9k
fix(run_in_container): drop hardcoded --full-auto flag #783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
fix(run_in_container): drop hardcoded --full-auto flag #783
Conversation
All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA |
36634fe
to
39ff37a
Compare
8df54a5
to
8518476
Compare
@@ -92,4 +92,4 @@ quoted_args="" | |||
for arg in "$@"; do | |||
quoted_args+=" $(printf '%q' "$arg")" | |||
done | |||
docker exec -it "$CONTAINER_NAME" bash -c "cd \"/app$WORK_DIR\" && codex --full-auto ${quoted_args}" | |||
docker exec -it "$CONTAINER_NAME" bash -c "cd \"/app$WORK_DIR\" && codex ${quoted_args}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of going in the other direction where we would replace --full-auto
with --dangerously-auto-approve-everything
since the Docker container is the sandbox. Is your motivation to add a weaker approval mode or a stronger one?
I guess from your screenshot you want to run it with --suggest
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My goal wasn’t to weaken or strengthen the default-approval policy, but to make run_in_container.sh
flag-agnostic so Linux users can supply any --approval-mode
(e.g., suggest
or even your proposed --dangerously-auto-approve-everything
).
The hard-coded --full-auto
prevented that.
This PR therefore just removes the fixed flag (no other behaviour change).
Also commands with the linux sandbox got really long in daily use.
My follow-up PR (#876) mounts ~/.codex
, letting users persist their own config/instruction presets—together these two patches give people more parity with the macOS workflow while still defaulting to Codex’s existing approval mode.
Making the Linux sandbox more user friendly was my initial goal.
This PR is the first step. trying to keep changes small and easy to review.
Happy to adjust if you’d prefer a different default. Let me know what you think!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated and tested both PR's.
Any thoughts ? - #876
What: This commit removes the hardcoded `--full-auto` flag from the `run_in_container.sh` script. Why: The `--full-auto` flag was hardcoded in the `run_in_container.sh` script, which is used to run Codex in a containerized environment. This flag was causing issues for users who wanted to run Codex with different approval modes or configurations. How: By removing the hardcoded flag, users can now specify their own approval modes and configurations when running Codex in a container. This change aligns the behavior of the containerized version of Codex with the behavior of the non-containerized version, allowing for greater flexibility and customization. Refs openai#781 - openai#781
8518476
to
be2176b
Compare
In run_in_container.sh Codex was started with hardcoded --full-Auto which makes it impossible for users to supply other
--approval-mode parameters.
Removing the flag lets Codex in a container respect CLI options on Linux the same way it does without the container.
Fixes: #781
PR-Checklist: