![[Figure 1: Codex prompts for manual approval when running Go tests, requiring a Yes or No selection]](https://media.shuijingwanwq.com/2026/11/01-codex-manual-approval-prompt.png)
Recently, I have been using OpenAI Codex to develop and maintain the Go Learning & Documentation Translations multilingual project. As the project scale continues to expand, the tasks Codex executes have become increasingly complex.
Some tasks take over ten minutes to run, while others may exceed half an hour. If they involve extensive Go testing, repository verification, or engineering fixes, the duration can be even longer.
The long execution time itself is not the biggest issue. What really inconveniences me is that Codex frequently asks me to choose Y or N during execution.
For example, when Codex is about to execute a command, the following options might appear:
- Yes, proceed
- Yes, and don’t ask again
- No, and tell Codex what to do differently
In the vast majority of cases, I simply choose the first option to allow Codex to proceed.
The problem is that I have to stay by the computer the entire time.
Suppose a task takes 30 minutes to run. If I step away to handle other things and Codex prompts for approval at the 5-minute mark, it might spend the next 25 minutes waiting for me to input Y instead of continuing to work.
This is clearly not how I want to work.
My goal is actually quite simple: give Codex a clear task, leave the computer for 30 minutes, and come back to check the execution results directly, rather than finding it stuck on an approval screen.
Through a practical configuration, I have essentially resolved Codex’s command execution approval issue and incidentally handled the write permissions for the Go build cache.
The complete process is documented below.
1. Root Cause: Go Tests Also Require Manual Approval
First, let’s look at a typical scenario I encountered previously.
Codex was handling a repository engineering issue in the project, modified some Go code and test files, and was about to execute:
go test -mod=readonly ./cmd/tour-i18n -run '^TestSiteContentCLIRejectsUnsafeInputs$' -count=1As a result, a manual approval prompt popped up.
![[Figure 1: Codex prompts for manual approval when running Go tests, requiring a Yes or No selection]](https://media.shuijingwanwq.com/2026/11/01-codex-manual-approval-prompt-1024x271.png)
The prompt also explained the reason: Go tests need to write to the build cache, but the sandbox sets the relevant cache directory to read-only.
From Codex’s security design perspective, this behavior is reasonable. By default, Codex should not arbitrarily modify files outside the workspace.
However, for my use case, these approvals happen far too frequently.
This is especially true for Go projects, where running tests is a very routine operation in daily development. If I have to manually approve it every time, it becomes difficult for Codex to continuously and autonomously complete long-running tasks.
Initially, I considered using the non-interactive mode of codex exec, but on second thought, this didn’t fit my daily workflow.
This is because I usually start Codex by entering the following command:
cd ~/code/go-tour-i18n
codexThen, in the interactive session, I continuously submit tasks, review results, and proceed with fixes.
I don’t want to have to exit the current session every time just to avoid approvals and restart the task using codex exec.
Therefore, I ultimately chose another approach: modify Codex’s global configuration so that standard interactive sessions no longer request command execution approval by default.
2. Locating Codex’s Global Configuration File
Codex’s user-level configuration file is located at:
~/.codex/config.tomlMy actual path is:
/home/wangqiang/.codex/config.tomlYou can open it with the following command:
nano ~/.codex/config.toml![[Figure 2: Codex global configuration file before modification, containing model settings and multiple trusted projects]](https://media.shuijingwanwq.com/2026/11/02-codex-existing-config-1024x753.png)
From the screenshot, you can see that the original configuration already contains quite a bit of content, for example:
service_tier = "default"
model = "gpt-6.1-sol"
model_reasoning_effort = "high"Additionally, it includes trust configurations for multiple projects:
[projects."/home/wangqiang/code/go-tour-i18n"]
trust_level = "trusted"I have configured a total of 11 projects.
Therefore, this modification had one important requirement: I could not overwrite the original configuration file just to add two permission parameters.
The model, reasoning effort, project trust settings, and terminal interface configurations all had to be preserved.
Ultimately, I used a Python script to automatically modify the TOML and verified configuration integrity before writing. This approach is much safer than manually deleting and rebuilding the entire file.
3. Setting Up Global Auto-Approval
There are only two core configurations that actually need to be modified:
approval_policy = "never"
sandbox_mode = "workspace-write"These two parameters serve entirely different purposes.
1. approval_policy = “never”
This configuration controls Codex’s command execution approval policy.
When set to never, Codex will no longer pause and wait for user approval to grant additional authorization for executing commands.
However, one detail must be clarified:
No longer requesting approval does not mean all operations will automatically be granted permission.
If an operation exceeds the scope allowed by the sandbox, Codex may still fail to execute it.
The difference is that it will no longer wait indefinitely for me to choose Y/N through the standard execution permission approval prompt.
This is exactly the problem I wanted to solve.
2. sandbox_mode = “workspace-write”
This configuration allows Codex to modify files within the current workspace while retaining sandbox restrictions.
Taking my Go project as an example, it typically needs to access the following directories:
| Directory | Purpose |
|---|---|
/home/wangqiang/code/go-tour-i18n | Read and write project source code |
/home/wangqiang/下载 | Read downloaded ZIP files and other attachments |
/tmp | Read and write temporary files |
For my environment, workspace-write is already sufficient to meet the primary write needs of the project workspace and /tmp.
The downloads directory usually only requires read access, so there is no need to grant additional write permissions.
I did not choose:
sandbox_mode = "danger-full-access"Because my goal was simply to reduce unnecessary manual intervention, not to give Codex unrestricted operation permissions over the entire system.
3. Configuration Modification and Verification
To avoid breaking the original configuration, I first backed up the file.
For users who want to do this manually, you can first execute:
cp ~/.codex/config.toml \
~/.codex/config.toml.bak-$(date +%Y%m%d-%H%M%S)Then, write the two parameters from above into config.toml.
Note: These two items are top-level TOML configurations and should be placed before the first [projects...] or any other configuration table; they must not be mistakenly written into a specific project’s configuration table.
I used an automated modification script to complete this step and checked the TOML syntax as well as whether the original configurations were preserved.
The final output was:
===== FINAL =====
RESULT=PASS
MODEL=gpt-6.1-sol
REASONING=high
APPROVAL=never
SANDBOX=workspace-write
PROJECTS_PRESERVED=11
TOML_VALID=PASSThis indicates that:
- The auto-approval configuration has been written.
- The sandbox mode is still
workspace-write. - The model and reasoning effort remain unchanged.
- All 11 original project configurations have been preserved.
- The TOML syntax check passed.
However, the configuration file check passing does not mean Codex has loaded the new configuration.
Therefore, I restarted Codex and entered:
/status![[Figure 3: Codex verifies the global configuration for the first time, Permissions shows Custom (workspace, never)]](https://media.shuijingwanwq.com/2026/11/03-codex-workspace-never-status.png)
The key output is:
Permissions: Custom (workspace, never)This shows that the new approval policy has been recognized by Codex.
At this point, I originally thought the configuration work could end.
But I subsequently realized there was another issue worth addressing together.
4. New Issue: Go Build Cache Directory is Read-Only
During a previous round of engineering fixes, Codex once reported:
Another test did not start because the default Go build cache is read-only; a temporary cache in /tmp will be used instead.
This issue is actually directly related to the manual approval prompts encountered earlier.
Go uses the build cache when running tests.
Typically, you can check the current Go cache location with the following command:
go env GOCACHEIn my Linux environment, the output is:
/home/wangqiang/.cache/go-buildHowever, this directory is located under the user’s home directory, which does not fall within the writable scope of Codex’s default project workspace.
Therefore, even after setting:
approval_policy = "never"It does not mean Codex can directly write to this directory.
This actually exposes an easily overlooked distinction:
The approval policy resolves whether manual confirmation is needed, while the sandbox policy determines what operation permissions the command actually possesses.
![[Figure 4: Codex uses a temporary /tmp cache to complete tests because the default Go build cache is read-only]](https://media.shuijingwanwq.com/2026/11/04-go-build-cache-readonly-fallback-1024x322.png)
The Codex in the screenshot adopted a temporary workaround:
GOCACHE=/tmp/go-tour-qc004-build-cache \
go test -mod=readonly ./internal/sitecontent \
-run '^TestQC004PackageScopeDiagnosis$' -count=1 -vThe corresponding test ultimately passed.
From the perspective of completing the current task, this approach is fine.
However, I don’t want to run it this way long-term.
This is because the temporary cache in /tmp might be cleaned up, and when different tasks use different cache directories, they cannot fully reuse existing build results.
For large projects that require repeatedly running Go tests, this could increase compilation time.
So, I decided to further adjust the configuration: keep the original Go cache location while granting write permission only to that specific directory.
5. Granting Write Permission Only to the Go Build Cache Directory
Codex’s workspace-write mode supports specifying additional writable directories.
The corresponding TOML configuration is:
[sandbox_workspace_write]
writable_roots = ["/home/wangqiang/.cache/go-build"]Note that /home/wangqiang/.cache/go-build is my actual path. Other users should first execute go env GOCACHE to confirm their own cache directory before making modifications.
If the configuration file already contains [sandbox_workspace_write], you only need to add or modify writable_roots within the existing configuration table; do not create duplicate TOML configuration tables.
Again, I used an automated modification script rather than directly rewriting the configuration file.
The script primarily accomplishes the following tasks:
- Read
go env GOCACHEto confirm the actual cache directory. - Check existing approval and sandbox configurations.
- Add the Go cache path to
writable_roots. - Preserve all other configurations and validate the new TOML.
- Back up the original file before writing.
The actual execution result:
BACKUP=/home/wangqiang/.codex/config.toml.bak-20261030-195107
===== FINAL =====
RESULT=PASS
GOCACHE=/home/wangqiang/.cache/go-build
WRITABLE_ROOTS=['/home/wangqiang/.cache/go-build']
APPROVAL=never
SANDBOX=workspace-write
PROJECTS_PRESERVED=11
TOML_VALID=PASSThis modification did not change the original Go cache location, nor did it open up the entire user home directory.
I simply added a specific directory that was previously unwritable into Codex’s sandbox writable scope.
From a permissions control perspective, this better fits my needs than using an unrestricted sandbox.
6. Final Verification: Codex Recognizes Go Cache Permissions
After completing the configuration, I re-entered Codex and executed again:
/status![[Figure 5: Codex final permission status, showing the Go build cache directory has been added to the writable workspace while maintaining the never approval policy]](https://media.shuijingwanwq.com/2026/11/05-codex-writable-go-cache-final-status.png)
This time, the displayed content differs from before:
Permissions: Custom (workspace [/home/wangqiang/.cache/go-build], never)Compared to the previous:
Permissions: Custom (workspace, never)The Go cache directory has been explicitly added.
This means Codex has loaded the new writable directory configuration.
As of this verification, what I can confirm is: the global auto-approval configuration has taken effect, and the newly added Go cache writable directory has also been recognized by Codex.
The Go tests using the /tmp cache previously passed successfully; however, this final status screenshot itself does not prove that all subsequent Go tests will succeed, nor does it replace actual cache read/write verification.
Nevertheless, for the goal of this configuration work, the key permission issue now has a clear solution.
7. Unattended Does Not Mean the Task Will Definitely Succeed
After completing these adjustments, Codex is now closer to the way I want to work:
Input a task, let it run continuously, step away from the computer temporarily, and check the execution results later.
However, I think it is necessary to distinguish between “unattended” and “guaranteed completion.”
Even after setting:
approval_policy = "never"The following situations can still cause tasks to be interrupted or fail:
- The task needs to access directories that have not yet been authorized.
- Network restrictions prevent access to certain dependencies or resources.
- The third-party program being run itself requires interactive input.
- Codex encounters a business problem it cannot decide on autonomously.
- Codex’s usage quota is exhausted or the network connection drops.
- The computer goes to sleep automatically, causing local tasks to stop.
Among these, closing the terminal and stepping away from the computer are not the same thing.
If you are just stepping away, keeping the Codex session running and preventing the system from sleeping is sufficient.
If you need to close the terminal or disconnect a remote connection, you should consider using tools like tmux to maintain the terminal session.
Therefore, this configuration resolves blockages like manual approvals, not all issues that might affect long-running tasks.
Additionally, I will still maintain stricter restrictions for production environment operations. Automatically modifying a local repository and automatically deploying a production service clearly carry different risks.
For operations like database deletions, online deployments, or sensitive configuration changes, permissions should not be unconditionally opened just to save a few confirmations.
8. Why Didn’t I Further Expand the Permission Scope?
After adjusting the Go cache permissions, I could have continued to open up more directories.
For example, allowing Codex to write to the downloads directory, or adding the entire user home directory to the writable scope.
But I didn’t do this.
The reason is simple: there is currently no actual need.
The problems encountered this time can be divided into two:
The first problem was the repeated command approval prompts, which required a unified solution.
The second problem was the inability to write to the Go build cache, which required a solution targeted at a specific directory.
Both problems have now found their corresponding configuration approaches.
As for other directories, there is currently no evidence that permissions must be increased, so naturally there is no need to modify them in advance.
I prefer to continue using this approach in the future:
First, use the current configuration. If a task actually fails due to insufficient permissions, then analyze the specific cause and only add the necessary permissions.
This reduces maintenance effort and avoids gradually losing control over Codex’s actual permission scope as the configuration continuously grows.
9. Summary: Reducing Wait Times is More Important Than Blindly Expanding Permissions
This configuration adjustment did not involve any complex engineering development.
What is truly important is clearly distinguishing between several different issues.
In the past, when Codex prompted Y/N, I usually just chose to allow it and continued working.
But as long-running tasks have increased, I began to realize: if an approval issue happens repeatedly, I shouldn’t always rely on manual handling each time.
By modifying ~/.codex/config.toml, I completed two key adjustments:
approval_policy = "never"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
writable_roots = ["/home/wangqiang/.cache/go-build"]This ultimately achieved the following configuration results:
| Item | Result |
|---|---|
| Standard interactive Codex | Continues to be used |
| Global command execution approval | No longer requires manual approval |
| Current project write permissions | Preserved |
/tmp temporary directory | Default writable capability preserved |
| Go build cache | Write access additionally authorized |
| Downloads directory | No additional write access granted |
| Other system directories | Not fully opened |
| Existing project and model configurations | All preserved |
For developers who frequently need to run tasks lasting tens of minutes, the benefits of this configuration are not necessarily reflected in how many seconds are saved on a single command.
Its more important value lies in: reducing the task execution process’s reliance on continuous human presence.
If a task actually only takes 30 minutes, but waits 25 minutes for me because of a single approval, then what is truly wasted is not computing resources, but the continuity of the entire workflow.
I hope my future collaboration with Codex will no longer be constantly guarding the terminal and clicking confirm, but rather defining the task goals and permission boundaries, and then letting it complete the work as independently as possible.
As for new issues that arise later, I will still insist on handling them on demand, rather than opening all permissions at once.
After all, letting AI work more autonomously does not mean having to give up control over the execution environment.
References