DEV Community: Yan Gao

Codex Full Access Is the Wrong First Question

Yan Gao — Mon, 21 Sep 2026 06:08:45 +0000

These commands do not grant the same authority:

codex -C C:\absolute\project --sandbox workspace-write --ask-for-approval never
codex --dangerously-bypass-approvals-and-sandbox

The first removes approval prompts while keeping a workspace boundary. The second removes both the approval and sandbox controls. The current codex-cli 0.155.1 help exposes them separately for a reason.

Do not copy either command until the failed boundary is known. When someone asks how to give Codex “full access,” the phrase usually hides a smaller problem:

approval prompts interrupt a non-interactive run;
one required folder sits outside the workspace;
a package manager cannot reach the network;
a domain allowlist is not being enforced;
or an external tool wants authority that the shell sandbox does not describe.

Treating all five as the same problem produces a broad permission change that may not even repair the failing gate.

The better first question is:

Which boundary stopped the task, and what is the smallest change that proves it?

Three controls that are easy to confuse

1. Approval routing

Approval policy determines whether Codex can pause and ask before an action. It does not, by itself, decide which files or network destinations the command can reach.

OpenAI's current documentation states that --ask-for-approval never works with every sandbox mode. A read-only run with no prompts is still read-only. A workspace-write run with no prompts is still bounded to its configured workspace and network policy.

2. The command execution boundary

The sandbox or permission profile controls the technical reach of generated commands. That includes filesystem access and, depending on the configuration family, command network access.

This is why workspace-write and danger-full-access are not different prompt settings. They are different execution boundaries.

3. External tool authority

Apps, MCP tools, hooks, browser actions, and other integrations may have their own approval and authorization paths. A shell flag is not a universal permission switch for every connected tool.

Removing shell prompts does not automatically authorize a side-effecting app action. Approving one external action does not necessarily widen filesystem access for later commands.

Translate the symptom before choosing a flag

What the operator actually needs	Narrow first move	What not to assume
Run inside one repository without interactive prompts	`--sandbox workspace-write --ask-for-approval never`	No prompts does not mean machine-wide write access.
Write to one known folder outside the project	Add that exact path with `--add-dir`	Do not open the parent drive or user profile.
Let a command reach the internet	Enable command networking in the selected configuration model	Web search availability does not prove subprocess network access.
Enforce a domain allowlist	Enable both profile networking and the network proxy	Domain entries alone do not activate enforcement.
Remove the local sandbox	Use dangerous full access only inside an externally isolated environment	Full access does not diagnose why the original task failed.

This table is a diagnostic order, not a recommendation to escalate through every row.

Network access has two separate switches

The current Codex permission-profile documentation makes an important distinction:

network.enabled = true permits commands to use the network.
features.network_proxy = true activates enforcement of the profile's domain rules.

With networking on and the proxy off, commands have direct network access and the domain rules do not constrain it. That is not an allowlisted setup, even if the TOML contains an allowlist.

A minimal named-profile shape looks like this:

default_permissions = "project-api"

[features]
network_proxy = true

[permissions.project-api]
extends = ":workspace"

[permissions.project-api.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-api.network]
enabled = true

[permissions.project-api.network.domains]
"api.openai.com" = "allow"

The important idea is not the example hostname. It is that filesystem scope, permission to use the network, and network-policy enforcement remain visible as separate decisions.

Do not mix this permission-profile model with legacy sandbox_mode settings in the same effective configuration. OpenAI currently documents them as alternative configuration families.

What I checked on the current Windows CLI

On September 21, 2026, the resolved local installation reported:

codex-cli 0.155.1

Its main help exposed:

read-only, workspace-write, and danger-full-access sandbox values;
on-request and never approval values;
--add-dir for an additional writable directory;
--dangerously-bypass-approvals-and-sandbox, labeled extremely dangerous;
and a separate codex sandbox -P <profile> path for checking a named permission profile.

I also preserved a failed check. Running this:

codex sandbox windows --help

did not display a Windows subcommand reference. The current CLI parsed windows --help as a command to run inside the sandbox, and that attempt failed. The verified current help form is:

codex sandbox --help

That failure is not evidence that the sandbox is broken. It is evidence that remembered syntax can be wrong even when the underlying idea is right. Check the installed CLI instead of copying an old command shape.

A five-minute boundary check

Before editing a real configuration:

Resolve every installed Codex command and record the active version.
Read the current help for the exact surface you will use.
Write down the one missing capability: prompt behavior, file read, file write, command network, or external action.
Start from a disposable project with no credentials or production scripts.
Test one operation that should succeed and one harmless operation that should be denied.
Inspect the resulting artifact outside Codex.
Change only one control before the next test.

If the first error changes after several settings change together, stop. You have lost the causal evidence needed to know which boundary mattered.

The practical rule

Use fewer prompts when the problem is prompts. Add one directory when the problem is one directory. Enable and constrain command networking when the problem is networking. Review external tools under their own authority model.

Full access is the last answer because it removes evidence as well as friction.

For the complete Windows decision matrix, current configuration families, default_permissions recovery, network-proxy checks, and rollback boundaries, use the Codex Windows permissions guide.

Sources

Disclosure: This article was drafted with AI assistance. The product facts were checked against current OpenAI documentation, and the CLI behavior was checked locally on the version named above. No credentials or user configuration were read.

Codex Sandbox Escape: What to Check Before Opening an Untrusted Repository

Yan Gao — Mon, 21 Sep 2026 05:56:22 +0000

Updating Codex is necessary. It is not the same as making an unknown repository trustworthy.

Two recently disclosed sandbox escapes make that distinction concrete:

Overpatch used attacker-controlled patch paths to widen where apply_patch could write.
Heapjack targeted the boundary between sandboxed JavaScript and a privileged native helper in Codex Desktop.

The researchers reported both issues to OpenAI on August 12, 2026 and say both were fixed within eight days. OpenAI's public Codex CLI 0.149.0 changelog independently records a fix that prevents apply_patch from widening write permissions.

The minimum version check

Run this before opening an unfamiliar repository:

codex --version

The current evidence supports these minimums:

Surface	Minimum	Evidence boundary
Codex CLI	`0.149.0`	OpenAI's release record includes the `apply_patch` permission fix.
Codex Desktop	build `26.818.21641`	This threshold is reported by the researchers and repeated by BleepingComputer.

Use a later stable build when available. Do not read this table as a claim that every possible sandbox weakness has been eliminated.

Why updating is only the first gate

A coding agent does more than display source code. Depending on its permissions and tool setup, it may:

read repository instructions and configuration;
launch package managers, test runners, hooks, or build scripts;
edit files in the workspace;
call MCP servers or other installed tools;
inherit access to credentials, sockets, or network destinations.

That means “take a quick look at this repository” is an execution decision, not merely a reading decision.

Patching fixes a known implementation bug. It does not remove malicious repository content, unsafe dependencies, exposed secrets, overpowered tools, or an operator approving the wrong action.

A safer untrusted-repository preflight

1. Separate the repository from valuable state

Use a disposable directory or VM that does not contain:

production .env files;
SSH keys or reusable access tokens;
cloud credentials;
browser profiles or session cookies;
production deployment scripts with active credentials;
writable mounts into important workspaces.

Do not treat “read-only” as permission to expose secrets. Heapjack matters precisely because a nominally restrictive mode did not contain the full attack path described by the researchers.

2. Identify the exact Codex surface

CLI, Desktop, IDE integrations, bundled binaries, and package-manager installs can resolve to different versions and helpers.

Record the surface and version you are actually testing:

codex --version
Get-Command codex -All | Select-Object Name, CommandType, Source, Version

A passing CLI check does not prove that a Desktop or IDE path uses the same components.

3. Start without repository-controlled execution

Before running installs, builds, tests, or hooks:

Inspect the top-level file names.
Read repository instructions as untrusted input.
Review package scripts and tool configuration.
Identify symlinks, submodules, generated binaries, and external tool definitions.
Decide which single command, if any, is justified next.

Do not start with npm install, a bootstrap script, or “fix everything.” Those actions dramatically expand the code and tools involved.

4. Use the smallest capability set

Begin with no network and no write access when the task permits it. If a later step needs one capability, grant that capability for a bounded task instead of widening the whole session.

Keep these decisions separate:

Can the agent ask for approval?
Can the process read or write this path?
Can it reach the network?
Can an installed tool act outside the repository?

An approval policy and a sandbox policy are not interchangeable.

5. Verify the artifact outside the agent

Do not accept “done” or exit code 0 as proof.

For any permitted edit, independently check:

the exact changed-path list;
unexpected files outside the intended directory;
symlink targets;
the required output's existence and hash when useful;
whether credentials, environment data, or unrelated files appeared in logs.

If the required artifact is absent, the task failed even if the final message says it succeeded.

Windows failures are a separate problem

Security patching and Windows sandbox troubleshooting should not be collapsed into one repair.

For example, CreateProcessWithLogonW failed: 1385 points to a Windows logon-right boundary for the sandbox user. Helper-not-found, setup refresh, UAC errors, token setup failures, read-only workspaces, and child-process denials occur at different gates.

I keep the complete Windows classification flow, redacted evidence packet, rollback boundary, and source list in this Codex Windows sandbox failure clinic. There is also a browser-local sandbox triage tool that classifies the first observed error without uploading logs.

A practical stop rule

Stop the run when any of these is true:

the resolved Codex version is below the required patched version;
the repository needs credentials before its purpose is understood;
a script asks for broader filesystem or network access than the task requires;
the first error changes after several settings are modified at once;
the agent reports completion but the required artifact cannot be independently verified;
the only proposed fix is to disable the sandbox or use unrestricted host access.

The safe response is not “try harder.” It is to preserve the first evidence, reduce the environment, and decide whether the repository deserves any execution authority at all.

Sources

Disclosure: This article was drafted with AI assistance and checked against the cited sources. Product release evidence, researcher claims, and operational recommendations are labeled separately.

What “Crawled – Currently Not Indexed” Looked Like on a 400-URL AI Site

Yan Gao — Sun, 20 Sep 2026 09:24:21 +0000

A few weeks ago, one of my AI workflow sites looked healthy in Google Search Console. Google was crawling it, the server was fast, and the sitemap was valid. Then impressions collapsed.

The useful part is that this was not a robots.txt bug, a manual action, or a security warning. It was a site-quality and prioritization failure.

The before-and-after

For two complete seven-day periods:

Aug 9–15: 2,030 impressions, 29 clicks, average position 16.9
Aug 16–22: 68 impressions, 0 clicks, average position 35.6

That is a 96.7% impression loss in one week.

What Google was telling me

The submitted-URL report showed:

68 indexed URLs
332 not indexed
162 “Crawled – currently not indexed”
170 “Discovered – currently not indexed”

Crawl stats were not the problem:

1,830 crawl requests
85% successful 200 responses
91 ms average response time
no manual action
no security issue

The site also had zero external links recognized by Search Console.

The mistake

The site expanded from roughly 246 indexable routes to 274 in a few days. Many pages covered release numbers, short-lived product changes, and closely related troubleshooting topics.

Each page could be factually correct and still fail the larger test: does this URL own a distinct user job, contain independent evidence, and deserve to remain useful after the release cycle ends?

Google crawled the pages. It did not choose to keep most of them in the index.

The recovery work

I stopped adding version-news pages and reduced the live sitemap from 400 reported URLs to 195 current routes.

The recovery sequence is now:

Keep one URL for one durable intent.
Merge overlapping answers.
Redirect superseded pages.
Return 410 only for content with no replacement.
Preserve pages with proven query demand.
Request indexing for a few demand-backed pages, not the entire site.
Build real citations instead of repeatedly submitting IndexNow.

For example, the page on Codex Windows permissions stays because Search Console showed real query demand and the page owns a specific troubleshooting job.

What I would do differently

I would not treat successful deployment, sitemap submission, or IndexNow acceptance as SEO progress. Those prove delivery, not ranking eligibility.

I would publish fewer pages, require a distinct search intent and evidence boundary for every route, and build external references before expanding the catalog.

The site is not “recovered” yet. The reduced sitemap has only just been resubmitted, and Google still has to reprocess it. I am publishing the failure pattern now because it is more useful than another generic indexing checklist.

These numbers come from one Search Console property. They document one recovery case; they do not prove a universal ranking factor.

Codex CLI 0.147: Test Agent Plugins, Approvals, and MCP Separately

Yan Gao — Sat, 15 Aug 2026 18:42:09 +0000

Codex CLI 0.147 combines several changes that affect different trust boundaries. Treating the upgrade as one pass/fail event misses the failures that matter.

The short answer

Test five things independently:

One portable Agent Plugin.
One --approve-for-me boundary.
One MCP server using the opt-in 2026-07-28 protocol.
One imported skill or conversation.
One interrupted Windows background process.

A successful launch proves only that Codex started. It does not prove that plugin provenance, approval scope, protocol negotiation, imported context, or process cleanup are correct.

Agent Plugins need a provenance receipt

Portable plugins can move instructions, tools, apps, and supporting files between environments. Before activation, record:

source repository and reviewed revision,
enabled scope,
declared tools and network destinations,
expected files or commands,
one allowed operation and one denied operation.

Then disable the plugin and start a fresh session. The capability should disappear. Catalog visibility is not execution proof.

`--approve-for-me` is not unrestricted execution

The flag adds automatic approval review. It does not erase the sandbox, network policy, managed restrictions, or the need to verify side effects.

Use a disposable workspace and check:

one operation that should be approved,
one operation that should remain denied,
the exact artifact created,
the command and network evidence,
the result after restarting the session.

Codex 0.147 also removes the deprecated codex exec --full-auto shortcut. Unattended workflows should declare sandbox and approval behavior explicitly.

MCP needs a protocol-level check

Opt-in MCP 2026-07-28 support adds capabilities such as paginated discovery and multi-round requests. A connected server can still fail during tool discovery, schema validation, one invocation, or response handling.

Record the negotiated protocol version, enumerate tools, call one bounded tool, and verify the artifact outside Codex.

Imported context needs ownership rules

Cursor-managed skills and imported Claude or Cursor conversations increase reusable context. They also increase the chance of stale instructions, duplicate guidance, and hidden conflicts.

Pin the source, inspect references, run a known-answer task, and confirm which instruction won when scopes conflict.

Windows needs a real interruption test

The release includes Windows process and path fixes. Verify them by starting a harmless bounded background task, interrupting it, and checking both the process tree and expected artifact state. A quiet terminal is not proof that the child process stopped.

Release gate

Upgrade only when every boundary has its own evidence receipt. If one check fails, roll back or disable only that capability instead of deleting unrelated configuration.

Official release:
https://github.com/openai/codex/releases/tag/rust-v0.147.0

Complete source-linked analysis and acceptance checklist:
https://tgwise.com/intelligence/codex-cli-0-147-agent-plugins-approve-for-me-mcp/

ChatGPT Agent Is Gone: How to Choose ChatGPT Work vs Codex

Yan Gao — Sat, 15 Aug 2026 18:41:30 +0000

ChatGPT agent is no longer available. Reinstalling the desktop app will not restore the old surface. OpenAI now separates longer non-code work, repository work, and browser authority across different tools.

The short answer

Use ChatGPT Work for research, analysis, documents, spreadsheets, presentations, reports, and Sites.

Use Codex for repository edits, tests, commands, code review, and software-development workflows.

Use the desktop built-in browser when the user can sign in and authorize specific tabs. Use the Codex Chrome extension when the task needs an existing Chrome profile, cookies, sessions, or extensions. The cloud browser is for supported public pages and should stop at sign-in or payment.

Why ChatGPT agent disappeared

This is a product transition, not a local installation failure. OpenAI's current guidance directs longer multi-step work and finished deliverables to ChatGPT Work while keeping Codex as the software-development surface.

If Work is missing, check plan eligibility, staged rollout, workspace role, model availability, and organizational policy before reinstalling anything.

Choose by final artifact

Ask what the workflow must produce:

A research packet, spreadsheet, presentation, report, or Site: choose ChatGPT Work.
A code change, test result, patch, command log, or repository review: choose Codex.
A task that must inspect an authenticated website: use a human-controlled signed-in browser surface.
A public-page lookup without authentication: cloud browser may be sufficient.

The name of the old tool is less important than the destination artifact and authority boundary.

Rewrite old agent prompts

Do not simply replace the words ChatGPT agent with ChatGPT Work. Rewrite the task contract to name:

The approved source set.
The final artifact and format.
The local files, connected apps, or browser tabs allowed.
Actions that require confirmation.
Review criteria, retry limit, and stop condition.
Evidence that proves the result outside the completion message.

This prevents an old prompt from silently carrying browser, credential, payment, or filesystem assumptions into a different execution surface.

Keep browser boundaries explicit

Cloud browser, the desktop built-in browser, the Chrome extension, connected apps, local files, and repository tools have different authority.

Do not paste passwords or payment details into a Work task.
Sign in yourself on the human-controlled browser surface.
Open only the minimum folder, app, or tab required.
Review consequential confirmations before they run.
Verify the final file and external state independently.

Migration checklist

Classify the old task by its final artifact.
Choose Work, Codex, or the appropriate browser surface.
Remove obsolete assumptions about the former agent interface.
Re-check plan and workspace eligibility.
Name protected actions and approval gates.
Run one bounded known-answer task before migrating scheduled work.

The complete source-linked transition map, browser boundaries, and operating checklist are available here:

https://tgwise.com/intelligence/chatgpt-agent-transitioned-to-chatgpt-work/

Claude Code Plugin Not Found: Diagnose Marketplace, Scope, or Runtime

Yan Gao — Sat, 15 Aug 2026 17:50:53 +0000

A Claude Code plugin can disappear for several different reasons, and the error message tells you which layer to inspect first. Do not start by deleting caches or reinstalling everything.

1. Freeze the exact error

These messages are not interchangeable:

marketplace not found: the catalog is not registered.
plugin not found: the marketplace is visible, but the exact plugin identifier is absent.
Installed but missing: check scope, enabled state, activation, loader errors, dependencies, and runtime paths.
/plugin or /reload-plugins unavailable: you may be using the wrong command surface or an unsupported environment.

Record the Claude Code version, terminal or desktop surface, exact marketplace name, exact plugin identifier, intended scope, and complete redacted error.

2. Prove the marketplace before the plugin

In a shell, inventory the registered catalogs:

claude plugin marketplace list

Inside an interactive Claude Code session, the official marketplace can be added with:

/plugin marketplace add anthropics/claude-plugins-official

If the named marketplace is not listed, stop at marketplace registration or policy. Installing the plugin again cannot repair an absent catalog.

3. Check the exact identifier and refresh boundary

Compare the full plugin-name@marketplace-name value with the Discover and Installed views.

Claude Code 2.1.221 introduced one stale-catalog refresh and retry when auto-update is enabled. On older versions, or when auto-update is disabled, update the exact marketplace once:

/plugin marketplace update MARKETPLACE_NAME

If the exact identifier still is not listed, do not loop updates or switch catalogs at random.

4. Separate scope, activation, and loader failures

A healthy install can still be hidden by user, project, local, or managed settings. Inspect structured state before adding another copy:

claude plugin list --json
claude plugin details PLUGIN_NAME@MARKETPLACE_NAME

Then check whether the plugin is enabled, whether the current session needs /reload-plugins, and whether the Errors tab reports a manifest, path, dependency, hook, MCP, or LSP failure.

5. Verify the runtime path

A Windows host path does not automatically exist inside WSL, a Dev Container, a cloud session, or another checkout. Verify required executables and plugin paths inside the same runtime that launches Claude Code.

Run one known-answer command, skill, agent, LSP action, or read-only MCP tool from the plugin. A successful install message is not the acceptance test.

What not to do

Do not delete plugin caches, rewrite shared settings, copy plugin directories across environments, or remove marketplaces before the first failed gate is proven. Preserve the evidence needed to distinguish catalog, scope, activation, loader, dependency, and runtime failures.

The full source-linked decision tree, commands, recovery boundaries, and official references are available here:

https://tgwise.com/guides/claude-code-plugin-not-found/

Claude Code 2.1.232: Six Regression Checks That Matter

Yan Gao — Sat, 15 Aug 2026 17:26:23 +0000

Claude Code 2.1.232 changes more than the version number. Forked subagents now inherit the full conversation and prompt cache by default, interactive non-teammate spawns move to the background, and Windows permission bypasses were closed.

That means a successful launch is not enough. Context inheritance, session routing, permissions, repository trust, MCP probes, and Remote Control recovery are separate operating boundaries.

1. Verify inherited context

Spawn one child agent with a harmless task. Confirm that it sees the intended parent context and does not inherit unrelated instructions.

2. Verify background completion

Start one interactive non-teammate child. Check that it moves to the background and that its final status returns to the expected parent session.

3. Verify session-name routing

Resume or message a session by name. Confirm the message reaches the intended session rather than another similarly named run.

4. Test one allowed and one denied write on Windows

Use a disposable fixture. Perform one harmless write inside the approved path, then attempt one write that should be denied. Both outcomes matter.

5. Check nested repository trust

Open a nested repository and verify that the trust boundary is explicit. Do not assume the parent repository's approval automatically covers every nested path.

6. Force a recovery path

Trigger one bounded MCP probe failure and one Remote Control resume. Confirm that tools, session state, and recovery messages remain coherent.

The acceptance rule

Use one symptom, one fixture, and one changed layer. A broad end-to-end run can pass while a permission or routing regression remains hidden.

The full source-linked checklist, including the official release evidence and rollback boundaries, is available here:

https://tgwise.com/intelligence/claude-code-2-1-232-forked-subagents-windows-permission-fixes/

Claude Code 2.1.226 vs 2.1.225: What Actually Changed

Yan Gao — Sat, 08 Aug 2026 15:30:45 +0000

Claude Code 2.1.226 and 2.1.225 landed close together, but they should not be treated as equivalent upgrade events.

The 2.1.226 release note is intentionally terse: it describes bug fixes and reliability improvements without listing a new workflow or user-facing capability. The concrete upgrade checks are concentrated in 2.1.225.

The actionable changes in 2.1.225

1. OAuth token precedence

Claude Code fixed refresh-token precedence when a long-lived CLAUDE_CODE_OAUTH_TOKEN is configured.

Why it matters: a valid long-lived token should not be displaced by a stale or unintended refresh path. Teams that inject credentials through CI, remote workspaces, or managed shells should re-test authentication after upgrading.

2. Workspace trust for `claude agents`

Running claude agents now prompts for workspace trust before it loads project-scoped agent definitions.

Why it matters: project configuration is executable influence. Trust must be decided before local instructions or agent definitions are accepted, not after.

3. MCP OAuth 401 recovery on macOS

The release fixes an MCP OAuth failure path caused by a Keychain read timeout that could surface as a 401.

Why it matters: if an MCP connector suddenly appears unauthorized even though the account is valid, the problem may be local credential retrieval rather than the remote service.

4. Remote Control recovery

Remote Control can resume more reliably after manual compaction.

Why it matters: long sessions frequently compact at the exact point where remote continuity matters. A release is only useful if the remote session remains recoverable after context maintenance.

5. Safer SendMessage routing

SendMessage behavior was tightened for named Remote Control sessions, including same-name safety.

Why it matters: a readable session name is not a unique identifier. Workflows that address multiple sessions should verify routing instead of assuming names cannot collide.

6. Gateway spend-limit warnings

Gateway users receive clearer spend-limit warnings.

Why it matters: an authentication-looking failure can actually be a quota or spend-limit condition. Operational checks should distinguish credentials, transport, provider status, and billing limits.

A practical upgrade acceptance test

Do not stop at claude --version. Run a small acceptance set:

Confirm the installed version in the same shell and runtime used for real work.
Test the configured OAuth token path in a fresh session.
Run claude agents inside a project that has local agent definitions and verify the trust prompt appears before those definitions are loaded.
Reconnect one MCP OAuth integration on macOS and confirm that an old 401 does not reproduce.
Start a Remote Control session, compact manually, and verify that the session resumes.
If you use SendMessage, test two similarly named sessions and confirm messages reach the intended target.
For gateway deployments, simulate or inspect a spend-limit condition and confirm it is reported distinctly from authentication failure.

This separates "the package updated" from "the workflow still works."

Primary sources

A source-mapped version of this diagnostic, including the upgrade checks, is maintained at TGWise Agent Lab.

Disclosure: I maintain TGWise Agent Lab. The linked page is an editorial diagnostic based on the official release notes; it is not affiliated with Anthropic.

Fix Codex default_permissions Without Disabling the Sandbox

Yan Gao — Fri, 07 Aug 2026 09:35:08 +0000

The Codex error saying that permission profiles exist without default_permissions is not a request to disable safety. It means the effective configuration contains profile definitions but does not select a default profile.

The fastest fix is to decide which configuration model the run should use.

Path 1: keep the legacy sandbox model

Use this path when the run already relies on sandbox_mode, approval_policy, or [sandbox_workspace_write] settings.

Keep those settings together and remove unused [permissions.*] blocks. An explicit --sandbox flag also selects this model for the run.

Path 2: use permission profiles

Use this path when you want a built-in or named profile. Remove loaded legacy sandbox_mode settings, set default_permissions, and provide the matching profile block.

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

Start from a bounded profile. Add filesystem or network exceptions only after the task proves it needs them.

No-prompt mode is not full access

approval_policy = "never" suppresses approval prompts. It does not widen the selected sandbox or permission profile. A workspace-bounded run remains workspace-bounded.

This distinction matters for unattended work. Removing prompts can make a bounded workflow repeatable, but it is not a substitute for defining the boundary.

Verify the effective run

Do not trust one TOML file in isolation. Record the Codex version, inspect every loaded config layer, resolve the named profile from the intended project root, and test write and network behavior with harmless operations.

A bounded profile-resolution probe on Windows is:

codex sandbox -P project-edit -C C:\absolute\project\path -- powershell -NoProfile -Command "Get-Location"

This proves the profile name resolves. It does not prove write or network behavior, so test those separately.

The complete decision table, Windows sandbox guidance, failure signatures, and six-step boundary checklist are in the canonical TGWise guide:

https://tgwise.com/guides/codex-windows-permissions/

Disclosure: I maintain TGWise Agent Lab.

Why Claude Code Ignores CLAUDE.md: Loading, Adherence, and Enforcement

Yan Gao — Fri, 07 Aug 2026 06:34:14 +0000

When Claude Code appears to ignore CLAUDE.md, rewriting the file is often the wrong first move.

The symptom can come from three different layers:

The instruction never entered the active session.
The instruction loaded, but the model did not follow it in the task.
The instruction describes an outcome that should have been enforced outside the model.

These layers need different fixes.

1. Prove the file loaded

Run /context and inspect the Memory files section. If the intended CLAUDE.md is absent, investigate the working directory, filename, exclusions, nested scope, and active settings sources.

Do not strengthen the wording of a file that is not in context.

2. Check scope and conflicts

A loaded instruction can still be irrelevant to the current path or conflict with user, project, nested, or path-scoped instructions.

Replace vague rules with observable behavior. A useful rule names:

when it applies;
the action to take;
the artifact or command that proves completion; and
the condition that blocks completion.

For example, "follow our API standards" is difficult to verify. "When editing src/api/**, run npm run test:api and report the failing test if it does not pass" is testable.

3. Test behavior instead of recall

Do not ask the model whether it read the file. Correctly repeating a rule proves recall, not compliance.

Run one bounded task where the rule creates a visible difference. Inspect the diff, command output, or generated artifact outside the chat. If the result matters, repeat the task in a fresh session.

4. Move critical boundaries out of prose

If a failure must never occur, CLAUDE.md should explain the boundary but should not be its only control.

Use the mechanism that can reject the bad outcome:

permissions or a sandbox for access boundaries;
PreToolUse hooks for command checks;
formatters and linters for deterministic style;
tests for behavior;
CI for release gates; and
human approval for irreversible external actions.

The practical rule is simple: use instructions for orientation and use tooling for enforcement.

The complete six-step diagnostic, current Anthropic sources, compaction checks, and a local decision tool are available in the original TGWise guide:

https://tgwise.com/guides/claude-code-ignoring-claude-md/

Disclosure: I maintain TGWise Agent Lab.

DEV Community: Yan Gao

Codex Full Access Is the Wrong First Question

Three controls that are easy to confuse

1. Approval routing

2. The command execution boundary

3. External tool authority

Translate the symptom before choosing a flag

Network access has two separate switches

What I checked on the current Windows CLI

A five-minute boundary check

The practical rule

Sources

Codex Sandbox Escape: What to Check Before Opening an Untrusted Repository

The minimum version check

Why updating is only the first gate

A safer untrusted-repository preflight

1. Separate the repository from valuable state

2. Identify the exact Codex surface

3. Start without repository-controlled execution

4. Use the smallest capability set

5. Verify the artifact outside the agent

Windows failures are a separate problem

A practical stop rule

Sources

What “Crawled – Currently Not Indexed” Looked Like on a 400-URL AI Site

The before-and-after

What Google was telling me

The mistake

The recovery work

What I would do differently

Codex CLI 0.147: Test Agent Plugins, Approvals, and MCP Separately

The short answer

Agent Plugins need a provenance receipt

--approve-for-me is not unrestricted execution

MCP needs a protocol-level check

Imported context needs ownership rules

Windows needs a real interruption test

Release gate

ChatGPT Agent Is Gone: How to Choose ChatGPT Work vs Codex

The short answer

Why ChatGPT agent disappeared

Choose by final artifact

Rewrite old agent prompts

Keep browser boundaries explicit

Migration checklist

Claude Code Plugin Not Found: Diagnose Marketplace, Scope, or Runtime

1. Freeze the exact error

2. Prove the marketplace before the plugin

3. Check the exact identifier and refresh boundary

4. Separate scope, activation, and loader failures

5. Verify the runtime path

What not to do

Claude Code 2.1.232: Six Regression Checks That Matter

1. Verify inherited context

2. Verify background completion

3. Verify session-name routing

4. Test one allowed and one denied write on Windows

5. Check nested repository trust

6. Force a recovery path

The acceptance rule

Claude Code 2.1.226 vs 2.1.225: What Actually Changed

The actionable changes in 2.1.225

1. OAuth token precedence

2. Workspace trust for claude agents

3. MCP OAuth 401 recovery on macOS

4. Remote Control recovery

5. Safer SendMessage routing

6. Gateway spend-limit warnings

A practical upgrade acceptance test

Primary sources

Fix Codex default_permissions Without Disabling the Sandbox

Path 1: keep the legacy sandbox model

Path 2: use permission profiles

No-prompt mode is not full access

Verify the effective run

Why Claude Code Ignores CLAUDE.md: Loading, Adherence, and Enforcement

1. Prove the file loaded

2. Check scope and conflicts

3. Test behavior instead of recall

4. Move critical boundaries out of prose

`--approve-for-me` is not unrestricted execution

2. Workspace trust for `claude agents`