Codex Keeps Asking for Approval? Check the Working Directory

If Codex asks you to approve the same shell command again after you chose Allow for this session, compare the command's working directory before changing your permission settings. A new open Codex bug report shows that the session approval lookup includes the current working directory. The same command can therefore miss its saved approval after the agent moves from one folder to another.

Keep the execution directory stable when you can. If a command needs to run in another folder, have Codex set the shell tool's working directory directly instead of wrapping the command in cd ... &&. For a command you genuinely trust across directories, review the exact prefix before choosing a narrow persistent rule. Do not turn on unrestricted access just to silence repeated prompts.

This guide covers repeated shell-command approvals. File-change approvals, network approvals, connector approvals, and prompts on native Windows can have different causes.

Confirm the Working Directory Is the Trigger

The August 8 report for openai/codex issue 37603 provides a small reproduction:

1. Run a shell command in one directory.

2. Choose Allow for this session.

3. Change to another directory.

4. Run the same command again.

5. Observe another approval prompt.

The report traces the behavior to UnifiedExecApprovalKey, which includes the environment, command, current working directory, terminal mode, and permission profile. A session approval is still stored, but the lookup can miss when the directory changes. The issue is open, so treat that root-cause analysis as a strong upstream report rather than a confirmed release note.

Before applying a workaround, record these details from two prompts:

If the command is the same and only the working directory changes, issue 37603 is a close match. If the command text changes, contains a new path, or is translated through another shell, a different approval key may be involved.

Do Not Solve This With Full Access

OpenAI documents sandboxing and approvals as separate controls. The sandbox limits what a command can touch, while the approval policy determines when Codex must stop and ask. The default local workspace mode is designed to allow work inside the active workspace while asking before actions such as leaving that boundary or using the network.

Unrestricted access removes a useful boundary and does not diagnose why an approval was repeated. Keep the current sandbox profile while you isolate the command, directory, and prompt type.

If the prompt follows a Windows sandbox failure rather than a directory change, use the Codex Windows sandbox diagnostic. If your concern is an agent deleting or overwriting files, use the separate file-deletion guardrail guide.

Also avoid editing ~/.codex/rules/default.rules by hand as a first response. A broad rule can outlive the session and authorize more commands than the prompt that annoyed you.

Step 1: Stop Embedding cd in the Command

An older Codex report, issue 7344, describes commands repeatedly prefixed with cd <path> &&. The shell tool already has a working-directory parameter. Putting cd inside the shell string changes the command shape and can make sandbox inspection or reusable approval matching more brittle.

Give Codex this instruction:

Run shell commands with the tool's working-directory parameter. Do not prepend cd ... && when the tool can set the directory directly. Show me the proposed command and working directory before requesting approval.

For example, prefer a command shaped like this:

command: pnpm test
working directory: /path/to/project

over this:

cd /path/to/project && pnpm test

This does not make every command approval-free. It keeps the directory in the field designed for it and makes the proposed scope easier to review.

Step 2: Keep Repeated Commands in One Execution Directory

If a task needs the same approved command several times, run it from one stable directory when the command supports that. Pass explicit file or package paths instead of moving the shell between subdirectories.

For a monorepo, that may mean using the package manager's directory or filter option from the repository root. For a test runner, it may mean passing the target test path while leaving the execution directory unchanged.

Do not force this pattern when the program genuinely depends on another working directory. The goal is to avoid incidental directory changes, not conceal a real scope change from the approval dialog.

Step 3: Choose a Narrow Persistent Rule Only When It Is Safe

Issue 37603 reports that Allow commands starting with... writes a persistent, directory-independent execution rule and continues to work after the working directory changes. That can be a practical workaround for a stable, low-risk command prefix.

Review the proposed prefix before accepting it:

• It should name a specific executable and safe subcommand.

• It should not be a generic shell, interpreter, package runner, or command that can execute arbitrary code.

• It should not include an unbounded wildcard or user-controlled expansion.

• It should not cover destructive flags, deployment commands, credential access, or network writes.

• You should be comfortable with the rule remaining after this task ends.

A narrow read-only status command is different from approving bash, sh, python, node, or a package executor as a reusable prefix. If Codex cannot show a safe, intelligible prefix, approve the individual command or decline it.

Step 4: Separate Similar Approval Bugs

Repeated prompts do not all share one cause. Use the visible request to classify the incident.

Issue 4212 is useful recurrence evidence, but it began as a native Windows command-vector mismatch. Its comments later accumulated reports from other environments and file-change paths. Do not assume that switching to WSL or changing trust settings fixes the newer working-directory-keyed report.

Step 5: Verify the Workaround Without Broadening Access

Use a harmless command that already triggered the repeated prompt. Then test one variable at a time:

1. Run it from the original working directory and approve it for the session.

2. Run the exact command again from the same directory.

3. Confirm whether Codex reuses the approval.

4. Change only the working directory.

5. Run the exact command again and record whether the prompt returns.

6. Restore the stable directory and repeat once more.

Success is specific: the approval is reused while the command and working directory remain identical, and a directory change reliably explains the miss. If prompts continue without either value changing, collect the Codex version, operating system, shell, terminal mode, permission profile, and the two sanitized approval requests for a separate report.

Do not paste private repository paths, environment variables, command output, or credentials into a public issue. Replace sensitive path segments while preserving whether the directory changed.

A Reusable Prompt for Codex

Use this bounded diagnostic before changing permissions:

Diagnose repeated shell-command approvals with read-only checks. For the last two approval requests, report the sanitized command shape, working directory, shell, requested permission, and approval choice. Determine whether only the working directory changed. Use the shell tool's working-directory parameter instead of embedding cd. Do not edit Codex rules, change the sandbox, enable network access, request full access, or run a write.

To verify whether the upstream reports have changed, start with the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then ask Aident Loadout to perform a read-only check:

Check Aident Loadout authentication and Vault status. Discover the current read-only GitHub issue Action, inspect its schema, and preflight requests for openai/codex issues 37603, 7344, and 4212. If the requests are valid and free, execute them. Return only each issue's state, updated time, labels, title, comments count, reactions count, and canonical URL. Do not comment, react, edit, close, or create anything.

Set up Aident Loadout and check the current approval reports.

Sources

• Working directory makes session approvals miss, issue 37603

• Excessive embedded cd commands trigger approval prompts, issue 7344

• Windows session approval is not remembered, issue 4212

• Request for clearer reusable approval scope, issue 17623

• Codex app-server approval protocol

• OpenAI agent approvals and security

Refresh this guide when issue 37603 is fixed or closed, when the session approval key changes, or when Codex documents a new directory-independent session approval contract.