DEV Community: Yan Gao

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 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`