Claude Code・Codex・Gemini-CLIの「Approve Once」問題と信頼永続化対策 An analysis of the 'approve once' trust persistence problem in AI coding agents like Claud…

As AI coding agents become a daily tool for developers, a subtle but serious design issue has surfaced: once a user approves a command or tool, many agents treat that approval as permanent. This article surveys how Claude Code, OpenAI's Codex CLI, and Google's Gemini-CLI handle trust persistence, and outlines the risks and mitigations around the so-called 'Approve Once' problem.

To reduce friction, each agent offers an option to permanently allow specific commands, directories, or tool categories. The convenience is real, but so is the attack surface. A blanket approval for tools like git, npm, or shell execution means that any prompt injection hidden in a README, issue comment, or transitive dependency could trigger destructive or exfiltrating actions without further user confirmation. The agent will faithfully follow instructions it believes to be legitimate, even when those instructions originated from untrusted content it merely read.

The author walks through the concrete permission models of each tool. Claude Code exposes an allowedTools configuration with wildcard support; Codex CLI relies on sandbox modes that constrain filesystem and network access; Gemini-CLI scopes permissions per project and per tool. The differences matter: a wildcard like Bash(*) effectively disables the safety layer, while command-specific allowlists such as Bash(git status) preserve much of the protection. Recommended mitigations include avoiding wildcards, splitting trust boundaries per repository, and reviewing persisted approvals periodically.

The broader context is worth noting. Throughout 2025, Anthropic and OpenAI have invested heavily in sandboxing agent execution, with devcontainer integrations and network isolation options becoming more standard. At the same time, several proof-of-concept prompt injection attacks targeting coding agents have circulated on GitHub and security blogs, suggesting that the industry's trust model for autonomous coding tools may need a more fundamental rethink. Some researchers argue that capability-based permissions, similar to mobile OS sandboxes, could replace today's coarse allow/deny prompts, though no consensus has emerged.

For practitioners, the immediate takeaway is to treat persisted approvals as a security configuration, not a convenience setting. Reviewing the settings.json or equivalent file of each agent, removing stale wildcard grants, and running agents inside containers when handling untrusted code are practical steps. As agents gain more autonomy — including background execution and multi-step planning — the cost of an over-permissive approval grows accordingly. The 'Approve Once' problem is unlikely to be solved by a single vendor; it appears to require coordinated changes in UX, sandboxing, and prompt provenance tracking across the ecosystem.