DEV Community: aicoding-guide

Gemini CLI v0.64 fixes the CPU hang on @ inside code and headless folder trust

aicoding-guide — Tue, 20 Oct 2026 19:18:57 +0000

Originally published at https://aicoding-guide.com.

Gemini CLI v0.64.0 adds no features. All 17 entries under "What's Changed" are fixes, refactors or release chores.

Two of them matter a great deal, though: a hang where piping code containing @ into -p pins the CPU at 100%, and a headless mode that treated untrusted folders as trusted. If the first sounds familiar, that alone is a reason to upgrade.

Key point
What this article covers

Why input like @scope/pkg hung the CLI, and the workaround that worked

How headless folder trust diverged from the actual trust decision

File writes and state persistence becoming atomic

Piping code with @ pinned the CPU at 100%

The fix is PR #29557 (Issue #29434). The symptom: piping code into -p on stdin made the CLI stop before it sent anything to the model. In the reporter's words, "The node process sits at ~100% CPU (state RN) indefinitely."

The trigger is input where an @-prefixed token is immediately followed by a double quote, with more quoted strings after it. In practice that means a scoped npm import.

import { x } from "@scope/pkg";
import { y } from "./local";

The symptoms were:

Aspect	Behaviour
Output	Nothing at all, not even an error
`--output-format stream-json`	Only the `init` event appears, then it stops
Signals	SIGINT and SIGTERM are ignored; only SIGKILL stops it
Versions reproduced	The reporter names v0.59.0 and v0.60.0

The reporter attributes the cause to the @-path regex matching across multiple quoted spans, so the result falls back to a glob whose large brace expansion minimatch then processes synchronously. That is the reporter's analysis; the fix itself is described only as stopping the CPU hang and quote swallowing caused by @ inside code.

A workaround if you cannot upgrade yet
The reporter writes that escaping every @ in the piped text avoids the hang. If a CI job pipes source code into gemini -p, add that preprocessing step until you can upgrade.

Headless treated untrusted folders as trusted

This is PR #29528 (Issue #29031). In headless mode (-p), the internal folder trust handling always passed the state through as trusted. The result was a mismatch: the warning said the folder was untrusted while the application-level check said it was trusted.

Folder trust exists to stop a project you have not vetted from loading its own configuration. According to the documentation, an untrusted folder disables all of the following:

The project's .gemini/settings.json is not loaded
The project's .env files are not loaded
Extensions cannot be installed, updated or uninstalled
Tool auto-acceptance is disabled, so every tool prompts
Automatic memory loading from directories in local settings is disabled
MCP servers are not connected
Custom .toml commands are not loaded, both project and user ones

So while the mismatch lasted, an untrusted folder's settings, hooks and MCP servers could still take effect in a headless run. If your CI relies on this feature, that is a reason to upgrade.

The docs disagree on the default
The settings table gives security.folderTrust.enabled a default of true. The Trusted Folders page says "The Trusted Folders feature is disabled by default." Both live on main in the same repository (checked 2026-10-21). Open /permissions to see which applies in your own setup.

To turn it on explicitly:

{
  "security": {
    "folderTrust": {
      "enabled": true
    }
  }
}

Decisions are stored in ~/.gemini/trustedFolders.json. Running headless against an untrusted folder exits with FatalUntrustedWorkspaceError, so a CI job that must proceed uses the --skip-trust flag or GEMINI_CLI_TRUST_WORKSPACE=true. For MCP configuration, see Setting up MCP servers in Gemini CLI.

Writes and state persistence became atomic

Three fixes address data corruption:

Fix	What changed
PR #29499	File tool operations are serialised and writes are atomic
PR #29558	State persistence is atomic, with recovery from a backup when the state is corrupt
PR #29568	Conversation recording uses append-only delta patching with bounded history windowing

These cover parallel file operations clobbering each other, and a state file left corrupt when the process dies mid-save. They matter most in long-running sessions.

Windows and interaction fixes

Four more that show up in daily use:

Windows ConPTY now forwards the IME cursor position (PR #29560), fixing misplaced cursors while composing text in an IME
Ctrl+C emergency abort now reaches the cancellation handler during active operations (PR #29586)
@file:line references and a ghost-text wrap hang are fixed (PR #29581)
Enter and Spacebar reliably confirm selection list options (PR #29502)

Beyond those, updating an extension on Windows now retries directory removal through file-locking errors (PR #29540), scroll position is preserved (PR #29520), and ACP resolves sessions by exact ID (PR #29580). For the previous release, see Gemini CLI v0.63 fixes the diff cannot spawn error.

Summary

v0.64.0 adds no features; all 17 "What's Changed" entries are fixes, refactors or release chores
Piping code containing @scope/pkg into -p no longer pins the CPU at 100%, a state only SIGKILL could end
Headless mode no longer treats an untrusted folder as trusted
File writes and state persistence are atomic, with backup recovery for corrupt state
The official docs give security.folderTrust.enabled both a true default and "disabled by default"

Codex CLI v0.163 turns Daybreak back on by default and makes /config searchable

aicoding-guide — Sun, 18 Oct 2026 19:19:07 +0000

Originally published at https://aicoding-guide.com.

Codex CLI v0.163.0 reverses a change that shipped five days earlier: Daybreak is on by default again. Alongside it come a searchable settings panel, mid-turn steering, and three security fixes in the network proxy.

Two things are worth acting on. If you had explicitly disabled Daybreak, check its current state. If you restrict network access in the sandbox, upgrade to 0.163.0.

Key point
What this article covers

Daybreak is the default again for eligible accounts

/config searches across categories, and you can steer a response mid-turn

The three fixes that landed in the network proxy

Daybreak is the default again

The release notes say "Daybreak is enabled by default for eligible accounts." In v0.161.0 it required --enable cli_daybreak or features.cli_daybreak=true, and daybreak=true alone was not enough. That requirement lasted five days.

# What v0.161.0 and v0.162.0 required
[features]
cli_daybreak = true

From v0.163.0, an eligible account does not need this. codex exec can also use Daybreak with an OpenAI API key now.

Do not treat this setting as settled
The same setting has moved twice in five days, and the release notes do not define what makes an account "eligible". If cli_daybreak is written into a runbook or a shared config.toml, verify the real behaviour after upgrading. What changed in Codex CLI v0.161 and v0.162 covers how it worked before.

/config and mid-turn control

How you find settings, and what happens when you interrupt, both changed.

Change	What it does
`/config`	Searches preferences across categories. Supported changes apply in place, and ones needing a restart are marked as such
Follow-ups mid-response	Send a follow-up while Codex is responding to steer it immediately
Interrupting a turn	Also stops running Code Mode cells and nested tool calls
Leader key in `/keymap`	The default is `Ctrl+X`. Voice mute moved to `F9`
`/daemon`	Restarts a managed background server, warning about work that may be interrupted
`/side`	A temporary side chat. It persists across thread switches, and prompt answers go back to the originating thread
Parallel read-only tools	Independent reads such as skills, memories and conversation history run in parallel

/config, /keymap and /daemon are not in the official list
As of 2026-10-19 the official slash command reference has no entry for /config, /keymap or /daemon. They appear only in the release notes. The reference does list /approve, /compact, /model, /plan, /review, /side, /status and /worktree, among others, and describes /side as "Start a temporary side chat without interrupting the main chat."

The network proxy and the sandbox

Three security fixes landed:

The network proxy now checks permission before a DNS lookup
It rejects duplicate Host headers
Credential aliases can no longer bypass the inspection hooks

The first matters most in practice. Previously name resolution could run ahead of the permission decision, so even a connection you blocked could leak to your DNS server which host was about to be contacted. Resuming a saved thread now also restores its permission and network approvals.

On the documentation side, the Linux sandbox section was updated. The official sandboxing page says that on Linux and WSL2 you install bubblewrap with your package manager first, that Codex uses the first bwrap executable it finds on PATH, and that without one it falls back to a bundled helper which "requires support for unprivileged user namespace creation". Codex shows a startup warning when bwrap is missing or the helper cannot create the namespace.

Glossary
bubblewrap (bwrap): a Linux sandboxing tool that isolates processes using namespaces without needing privileges. Codex uses it to limit where commands can write and what they can reach over the network.

The release notes say the Linux sandbox documentation now also explains seccomp, but as of 2026-10-19 no mention of seccomp could be found on the official sandboxing page. For how approvals and the sandbox interact, see Combining approval_policy and sandbox_mode in Codex.

The bundled zsh is gone

Codex no longer bundles a patched zsh and uses its standard shell executor instead. Configurations that use the retired shell flags get a migration notice.

The names of those flags could not be confirmed in the official configuration reference, so if the notice appears, follow what the message itself says. For the structure of the configuration file as a whole, see Configuring Codex with config.toml.

Two smaller items: the Linux and macOS release binaries are smaller because symbols are stripped from the packaged copies, and codex exec no longer repeats file diffs after unrelated commands. Clipboard paste handling on Windows and WSL was also fixed.

Summary

v0.163.0 makes Daybreak the default for eligible accounts; cli_daybreak is no longer needed
/config searches settings across categories and marks changes that need a restart
You can send a follow-up mid-response, and interrupting also stops Code Mode cells
The network proxy checks permission before a DNS lookup and rejects duplicate Host headers
/config, /keymap, /daemon and the retired shell flag names could not be confirmed in the official docs

This week in Claude Code, Codex and Gemini CLI (week of October 18, 2026)

aicoding-guide — Sat, 17 Oct 2026 19:13:13 +0000

Originally published at https://aicoding-guide.com.

The change with the widest reach this week is idle compaction in Claude Code. Leave a long conversation sitting and it now gets summarised on its own.

On the Codex side, Daybreak is enabled by default again — a setting that only became an explicit opt-in five days earlier in v0.161.0. It has flipped twice in under a week.

Key point
This week in brief

Claude Code compacts idle conversations automatically (idleCompaction turns it off)

Codex 0.163.0 made Daybreak the default for eligible accounts again

CLAUDE_CODE_DISABLE_FILE_MENTIONS and CLAUDE_CODE_AUTO_MODE_MODEL were added

Claude Code

Four releases this week, 2.1.299 through 2.1.302.

Idle compaction arrived (2.1.299, 2.1.302)

The CHANGELOG wording is: "Added idle compaction in the terminal: a 200K+ token conversation left idle for about 54 minutes is compacted before its one-hour prompt cache expires, so your next message doesn't reprocess it all."

The motivation is cost. Leave a conversation above 200K tokens idle for roughly 54 minutes and it is summarised before the one-hour prompt cache expires, so your next message does not pay to reprocess everything. The prompt caching documentation also notes that Claude Code may compact when idle, and that idleCompaction disables it.

Setting	What it does
`"idleCompaction": false`	Turns off automatic idle compaction (v2.1.290+)
`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS`	Changes the 200K token threshold (v2.1.290+)
`Idle compaction` row in `/config`	Toggles it from the UI (added in v2.1.302)

Know what compaction drops before you leave it on
Compaction replaces the conversation layer with a summary. CLAUDE.md itself is re-read from disk, but the contents of files that Claude read because CLAUDE.md told it to are folded into the summary. Context management with /compact and /clear covers the difference. If your workflow depends on what is in the window, turn it off.

New environment variables (2.1.299, 2.1.301, 2.1.302)

Variable	What it does
`CLAUDE_CODE_DISABLE_FILE_MENTIONS`	Claude gets the paths of `@` file mentions rather than their contents, and reads them with its own file tools
`CLAUDE_CODE_AUTO_MODE_MODEL`	Chooses the model the client-side auto mode classifier uses. It does not change server-side auto mode
`CLAUDE_CODE_RETRY_WATCHDOG_MAX_USAGE_LIMIT_WAIT_MS`	In unattended retry mode, exits instead of waiting out a usage limit whose reset is too far off

CLAUDE_CODE_DISABLE_FILE_MENTIONS is the useful one if @-mentioning a large file keeps filling your context in one shot.

Security fixes (2.1.301, 2.1.302)

The Read tool loaded an image file of any size — or a pipe or device named like an image — entirely into memory. Image sources over 128 MB are now refused
Quitting removed a worktree made by a WorktreeCreate hook without asking, even when it might hold unpushed commits

Telemetry

The OpenTelemetry api_request event now splits cache writes by lifetime with cache_creation_5m_tokens and cache_creation_1h_tokens. The tool_decision event gained classifier_verdict, permission_mode and classifier_category, so you can tell an auto mode classifier decision apart from one made by a permission rule.

Codex

Daybreak is the default again (0.163.0)

/config and steering (0.163.0)

/config: search preferences across categories, change supported ones in place, and see which changes need a restart
Follow-ups mid-response: send a follow-up while Codex is responding to steer it immediately. Interrupting a turn also stops running Code Mode cells and nested tool calls
Leader key in /keymap: the default is Ctrl+X. Voice mute moved to F9
Parallel read-only tools: independent reads such as skills, memories and conversation history now run in parallel

Network and sandbox (0.163.0)

Three proxy fixes landed: the network proxy now checks permission before a DNS lookup, rejects duplicate Host headers, and prevents credential aliases from bypassing inspection hooks. Resuming a saved thread now restores its permission and network approvals too.

One operational change: Codex no longer bundles a patched zsh and uses its standard shell executor instead. Configurations using the retired shell flags get a migration notice.

Gemini CLI

v0.64.0 is fixes only. The notable ones: a CPU hang and swallowed quotes when @ appears in code, file tool operations serialised with atomic writes, and atomic state persistence with recovery from a backup when the file is corrupt. On Windows, ConPTY now forwards the IME cursor position.

What to check now

Decide how you feel about idle compaction. If you do not want conversations summarised unprompted, turn it off in /config or with "idleCompaction": false
If you had explicitly disabled Daybreak in Codex, check its current state — the default moved
Upgrade Claude Code to 2.1.302 or later if the Read tool image issue matters to you
Upgrade Codex to 0.163.0 if you restrict network access in the sandbox, for the pre-DNS permission check

Summary

Claude Code now compacts idle conversations: 200K+ tokens left for about 54 minutes
Turn it off with "idleCompaction": false, tune it with CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS, toggle it in /config
CLAUDE_CODE_DISABLE_FILE_MENTIONS passes @ mentions as paths instead of contents
Codex 0.163.0 made Daybreak the default again for eligible accounts, reversing v0.161.0
Gemini CLI v0.64.0 is fixes only

Claude Code on Windows, native or WSL, and what trips people up

aicoding-guide — Fri, 16 Oct 2026 19:22:28 +0000

Originally published at https://aicoding-guide.com.

Claude Code started out aimed at macOS and Linux, with Windows users pointed at WSL. There is now a native Windows build you can run straight from PowerShell. Which one to choose comes down to one question: do you need sandboxing?

This article compares the two, gives the install steps for each, and collects the things that actually trip people up.

Key point
What you will learn

Native versus WSL, and the sandboxing difference that decides it

Install steps for each, and whether Git for Windows matters

The gotchas: hooks, paths, encoding and line endings

Native versus WSL 2

	Native Windows	WSL 2
Runs on	Windows directly	Linux inside WSL (Ubuntu, etc.)
Requires	Nothing; Git for Windows is optional	WSL 2 enabled
Sandboxing	Not supported	Supported
Shell tool	Git Bash when Git for Windows is installed, otherwise the PowerShell tool	bash / zsh
Where projects live	Windows drives (`C:\...`)	Inside WSL (`/home/...`) is recommended
Linux tooling such as Docker	Needs a Windows build	Linux builds work as-is
Suits	Windows-native development (.NET, Node)	Linux toolchains, or sandboxed command execution

WSL 1 is the third option, for when WSL 2 is unavailable; like native Windows, it does not support sandboxing.

Touching Windows files from WSL is slow
Working on a project under /mnt/c/... from WSL makes file I/O dramatically slower. If you choose WSL, keep the project inside WSL, under ~/projects/ for example.

Installing the native build

1. Git for Windows (optional)

The documentation calls Git for Windows optional. With it, Git Bash backs the Bash tool; without it, Claude Code runs shell commands through the PowerShell tool. If your hooks and scripts assume bash, install it. The defaults from Git for Windows are fine.

With Git for Windows installed, the PowerShell tool is available alongside Bash: on by default for claude.ai and Console accounts, and enabled with CLAUDE_CODE_USE_POWERSHELL_TOOL=1 in Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry sessions. Set it to 0 to turn the tool off.

2. Install Claude Code

Open PowerShell and run:

irm https://claude.ai/install.ps1 | iex

In CMD the command is different — your prompt shows PS C:\ in PowerShell and C:\ without the PS in CMD:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

WinGet works too, but a WinGet install does not auto-update, so run winget upgrade Anthropic.ClaudeCode periodically:

winget install Anthropic.ClaudeCode

The npm package is another option and needs Node.js 22 or later. You do not need to run the installer as Administrator.

3. Start it and check

cd C:\path\to\project
claude

The first run prompts you to log in. claude doctor reports installation health and settings-file validation errors without starting a session.

If Claude Code cannot find Git Bash, point at it in your settings file:

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

Installing in WSL

Sandboxed command execution requires WSL 2; WSL 1 does not support it.

Run wsl --install in an elevated PowerShell and restart. Ubuntu is installed by default.
Open the Ubuntu terminal and install Node.js if you plan to use the npm package (nvm is the easy route).
Install with the Linux command — you run it inside the WSL terminal, not from PowerShell or CMD:

curl -fsSL https://claude.ai/install.sh | bash

For VS Code, install the WSL extension, open a folder inside WSL, and install the Claude Code extension into WSL.

What trips people up

Hooks and scripts run through Git Bash

With Git for Windows installed, the Bash tool uses Git Bash, so PowerShell cmdlets are not available directly. Invoke PowerShell explicitly instead:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "powershell -NoProfile -File .claude/hooks/format.ps1"
          }
        ]
      }
    ]
  }
}

For hook basics, see Run lint and format on save with Claude Code hooks.

Writing paths

In permission patterns and CLAUDE.md, forward slashes (src/**) work on Windows too. Avoid backslashes, which need escaping inside JSON.

Encoding

If command output comes back garbled, set PowerShell's output encoding to UTF-8:

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

Line endings

A CLAUDE.md or hook script saved with CRLF by a Windows editor can fail under Git Bash when a stray \r ends up in the script. Set *.sh text eol=lf in .gitattributes and save scripts with LF.

Summary

Install natively from PowerShell with irm https://claude.ai/install.ps1 | iex; Git for Windows is optional, and without it the PowerShell tool runs commands
Sandboxing means WSL 2. Native Windows and WSL 1 do not support it. Keep projects inside WSL when you go that route
Write hooks and scripts for Git Bash, and keep line endings at LF
Fix garbled output with UTF-8 output encoding, and use forward slashes in paths

Run Claude Code in GitHub Actions with claude-code-action

aicoding-guide — Fri, 16 Oct 2026 19:22:27 +0000

Originally published at https://aicoding-guide.com.

Comment "@claude fix this bug" on an issue and have Claude Code implement the fix and open a pull request. Have a review appear automatically when a PR opens. Both come from the official claude-code-action, configured with workflow files in your repository.

This article covers setup, the two basic configurations — mention response and automated review — and how to limit permissions and cost.

Key point
What you will learn

Setting up with /install-github-app, and which authentication secret to use

The workflow that responds to @claude mentions

The automated review workflow, who can trigger runs, and how to cap cost

Setting up

Run /install-github-app from Claude Code inside the repository. It installs the Claude GitHub App, sets up the authentication secret, and pushes a branch with the workflow files, opening a pull request for you to create. You need admin access to the repository, and the GitHub CLI installed and authenticated with gh auth login.
Register the authentication secret. Use ANTHROPIC_API_KEY for a Claude API key from the Claude Console, or CLAUDE_CODE_OAUTH_TOKEN for a subscription token generated with claude setup-token. In the workflow, pass them to anthropic_api_key and claude_code_oauth_token respectively.
Create and merge the pull request. @claude then works in the repository.

/install-github-app only works with github.com repositories; on a gitlab.com or bitbucket.org remote it prints a notice and exits. For manual setup, install the Claude GitHub App yourself, add the secret, and copy examples/claude.yml into .github/workflows/.

Glossary
The GitHub App and GITHUB_TOKEN: by default the action authenticates as the Claude GitHub App. If you pass github_token: ${{ secrets.GITHUB_TOKEN }} instead, GitHub won't trigger workflows on the commits Claude makes — the documented fix for "CI not running on Claude's commits" is to remove that line.

Configuration 1: respond to @claude mentions

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

id-token: write is required for the action's default GitHub App authentication, and actions: read lets Claude read CI results on PRs. With no prompt input, the action runs in interactive mode and waits for the trigger phrase — @claude by default, changeable with trigger_phrase.

Requests that work well:

On an issue: "@claude reproduce this and open a PR with a fix"
On a review comment: "@claude add error handling to this function"
On a PR: "@claude add tests for what this change affects"

Configuration 2: review automatically when a PR opens

Supplying a prompt input puts the action in automation mode, which runs without waiting for a mention. The configuration the documentation now shows calls the code-review plugin's skill rather than a free-text prompt:

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

Without --comment, nothing is posted
In automation mode, "By default, results appear in the workflow run log rather than a comment." --comment is what makes Claude post on the pull request. Keep the claude_args line too: even though the skill's own allowed-tools frontmatter names the same tool, the action starts the inline-comment MCP server only when --allowedTools in claude_args names it.

With a free-text prompt you have to grant the tools yourself: "For a plain-text prompt, Claude has no shell or GitHub API access until you grant the tools the prompt needs" — through --allowedTools in claude_args, or a permissions.allow rule in the settings input.

Claude skips draft and closed pull requests, ones it judges not to need review, and ones that already carry a comment from Claude.

Limiting permissions and cost

Goal	How
Keep outsiders from triggering runs	Already checked by the action (see below). Narrow further with an `if:` on `github.event.comment.author_association`
Minimize write access	Give the review workflow `contents: read`
Restrict the tools	Pass `--allowedTools` in `claude_args`
Cap the work per run	Pass `--max-turns`, and set a workflow-level timeout
Enforce your project's rules	Put them in the repository's `CLAUDE.md`, which the action reads

Glossary
Who can trigger a run is checked by the action itself: two checks run before Claude starts, and the run fails if either rejects it. Write access — on issue and pull request events the triggering user must have write access to the repository; to allow specific users without it, set allowed_non_write_users and pass your own github_token. Human actor — a bot actor is rejected unless listed in allowed_bots, which keeps bots from triggering Claude in a loop. That check also applies to scheduled runs, which GitHub attributes to a repository user.

Secrets and pull requests from forks
On public repositories, GitHub withholds secrets from runs triggered by fork pull requests, so a review workflow runs only on pull requests from branches in the same repository. Before reaching for pull_request_target to change that, understand that it runs the fork's code with your secrets available.

How this relates to CLAUDE.md

Claude inside the action reads the repository's CLAUDE.md the same as it does locally — the documentation lists "Define project standards in CLAUDE.md" as a best practice, and notes that Claude reads it on every run, so keeping it concise also keeps cost down. Review criteria and prohibitions belong there rather than in the workflow's prompt, so you maintain one copy (How to write CLAUDE.md).

For a lighter setup that calls claude -p directly instead of using the official action, see Run Claude Code headless in CI.

Summary

/install-github-app installs the app and workflows; register ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN as the secret
No prompt means interactive mode and the @claude trigger; a prompt means automation mode
In automation mode results go to the run log unless you pass --comment and name the inline-comment tool in claude_args
Write access and a human-actor check already gate who can trigger runs; allowed_bots and allowed_non_write_users adjust them
Keep review criteria in CLAUDE.md, and cap cost with --max-turns, a smaller model, and workflow timeouts

Review debt in the AI era cannot be repaid by reading more

aicoding-guide — Thu, 15 Oct 2026 19:17:36 +0000

Originally published at https://aicoding-guide.com.

Review debt cannot be repaid by reading more. It can only be repaid by shrinking the unit you ship, by letting machines fail what they can, or by making the risky thing impossible in the first place.

The first thing an AI coding tool breaks is the balance between writing and reading. Generation gets several times faster; the rate at which a person reads a diff and judges whether it is right does not. What piles up in that gap is review debt.

Everything below rests on the Claude Code documentation as fetched on 2026-10-16.

Key point
What you will learn

Why adding reviewers does not close the gap

Three ways to repay the debt, and the mechanism behind each

When the argument fails

Headcount does not catch up

Start with the direction parallelism pushes. On agent teams the documentation says: "Agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode." Tokens stand in for output volume: raise the parallelism and the pile grows faster than the number of people reviewing it.

Adding reviewers has its own ceiling. You can add readers; you cannot reduce the context each change requires. Readers who don't share that context add variance in judgment, not throughput.

What has to change is not the supply of reading but the demand for it.

One: shrink the unit you ship

Agree on direction before the diff gets large, rather than reading it afterwards. This is why the documentation recommends plan mode: "Claude explores the codebase and proposes an approach for your approval, preventing expensive re-work when the initial direction is wrong."

What the human reads there is an approach, not code. The reading shrinks by an order of magnitude, and so does what you throw away when it's wrong (Claude Code plan mode).

A second move: keep things out of the diff entirely. Exploration produces no code but fills your context. The docs put it plainly — "Delegate the exploration so only the findings come back" and "The subagent reads files in its own context window and reports a summary" (Create subagents in Claude Code).

Two: let the machine fail it first

Before a person reads, let the machine reject what it can — the review-stage version of the previous essay's point that only what can fail is a fixed point.

The tools now ship this idea themselves. The auto mode description reads: "In auto mode, a second model, the classifier, reviews actions instead of you." Instead of you. Part of review has already moved from humans to machines.

Hooks do the same job. In v2.1.295, command and HTTP hooks gained onFailure: "block": a hook that can't start, times out or exits unexpectedly now blocks rather than letting the action through. A broken check no longer waves things past, which is what makes a machine pass trustworthy before the human one (Run lint and format on save with Claude Code hooks).

Where nobody is watching, this layer is the review (Run Claude Code headless in CI).

Three: make it not happen

The third route removes the thing to review: an action that never ran needs no reviewing.

What does the work here is permissions, not requests to the model: "Permission rules are enforced by Claude Code, not by the model," and instructions in your prompt or CLAUDE.md shape "what Claude tries to do" but not "what Claude Code allows."

In practice, convert the comments you keep writing in review into deny or ask rules. "Never touch the production config" and "always stop before a push" are more reliable as one rule each than as a comment every time, and once written they leave the review queue (Design permissions in Claude Code's settings.json).

Objections and limits

Some mistakes no machine catches. Design soundness, a misread domain, a wrong specification — none of these fail a test, a hook or a classifier. The auto mode docs note that "Explicit ask rules still force a prompt", assuming a human stays in the loop by design. Machine review narrows what a person looks at; it does not replace them.

Shrinking each change hides the whole. The smaller the diff, the easier it is to miss that the design is drifting. That is why the first route is "agree the approach before splitting", not "split". Skip the agreement and the debt moves into the design.

You can only constrain known risks. A deny rule names a danger you already thought of. A new category gets caught in review the first time, always. Permission design fixes the output of review, not its input.

Some work doesn't carry this debt. Throwaway prototypes and scripts with no external effect — there, repaying review debt costs more than it returns.

Summary

Output scales with parallelism; the context each change needs does not, so more reviewers never catch up
Route one: agree the approach before the diff grows — plan mode's documented rationale
Route two: let machines fail it. The auto mode classifier reviews "instead of you"
Route three: constrain with permissions. An action that never ran is never reviewed
The limits: design errors fail nothing, small diffs hide drift, and you can only constrain known risks

Getting started with Claude Code, from install to your first hour

aicoding-guide — Tue, 13 Oct 2026 19:16:42 +0000

Originally published at https://aicoding-guide.com.

Two things trip people up on a first install of Claude Code: which install method to pick, and what to check once it is in.

The short answer: pick the install method by whether it auto-updates. Only the native installer and npm update themselves; Homebrew, WinGet and the Linux package managers are manual. Then verify with claude --version and claude doctor before starting your first session.

Everything below comes from the official documentation as fetched on 2026-10-14. For what Claude Code is, see What Claude Code is; this page goes in the order you actually type things.

Key point
What you will learn

The system requirements and which plans include Claude Code

How to choose an install method (it comes down to auto-updates)

Your first session, and what to touch in the first hour

Requirements and the plans that include it

Item	Requirement
OS	macOS 13.0+, Windows 10 1809+ or Windows Server 2019+, Ubuntu 20.04+, Debian 10+, Alpine Linux 3.19+
Hardware	4 GB+ RAM, x64 or ARM64
Shell	Bash, Zsh, PowerShell or CMD
Network	An internet connection is required

The free plan does not include it
Claude Code requires a Pro, Max, Team, Enterprise or Claude Console account. The documentation is explicit: "The free claude.ai plan does not include Claude Code access." Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry also work. For what each plan costs, see Claude Code pricing and plans.

Choose an install method by its update behavior

This is the first fork in the road. Only the native installer and npm update themselves.

Method	Command	Auto-updates
Native (recommended)	`curl -fsSL https://claude.ai/install.sh \	bash`
Homebrew	`brew install --cask claude-code`	No
WinGet	`winget install Anthropic.ClaudeCode`	No
apt / dnf / apk	Register the repository, then install	No
npm	`npm install -g @anthropic-ai/claude-code`	Yes

On macOS, Linux and WSL the native install is one line:

curl -fsSL https://claude.ai/install.sh | bash

On Windows the command depends on your shell. Your prompt shows PS C:\ in PowerShell and C:\ without the PS in CMD.

irm https://claude.ai/install.ps1 | iex

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

The install command shows no progress while it downloads. When it finishes, open a new terminal window before checking.

Glossary
Release channel: the autoUpdatesChannel setting takes "latest" (the default — new versions as they ship) or "stable" (typically about a week old, skipping releases with major regressions). Homebrew picks by cask name instead: claude-code is stable and claude-code@latest is latest.

The npm package needs Node.js 22 or later. Do not use sudo npm install -g — the documentation warns it leads to permission issues and security risks.

Verify, then start your first session

claude --version

A working installation prints a version number such as 2.1.211 (Claude Code). If you get command not found, the install directory is not on your PATH yet.

For a fuller check, claude doctor prints read-only installation and settings diagnostics without starting a session: install health, settings-file validation errors, and warnings with suggested fixes. It also reports the result of the most recent update attempt.

claude doctor

Then start it in the project you want to work in:

cd /path/to/your/project
claude

The first run prompts you to log in through your browser. If you have set ANTHROPIC_API_KEY and you approve the key when Claude Code asks whether to use it, the login prompt is skipped. Once you are logged in, the credentials are stored.

What to decide on Windows

Windows gives you native or WSL, and the difference that matters most is whether sandboxing is available.

Option	Sandboxing	When to use
Native Windows	Not supported	Windows-native projects and tools
WSL 2	Supported	Linux toolchains, or sandboxed command execution
WSL 1	Not supported	If WSL 2 is unavailable

On native Windows, Git for Windows is optional but worth having: it provides Git Bash, which backs the Bash tool. Without it, Claude Code runs shell commands through the PowerShell tool. If Git Bash cannot be found, point at it in settings:

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

The first hour

Once a session is open, work through these in order.

Check the permission mode. It shows in the status bar. With v2.1.283 or later, terminal and VS Code sessions start in auto on every plan. Shift+Tab cycles modes at any time. The six modes are compared in Claude Code permission modes
Have it explain the project. Just ask what does this project do? — Claude reads the files it needs, so you don't add context by hand
Create a CLAUDE.md. /init scaffolds one for the project. For what to put in it, see How to write CLAUDE.md
Send one small change. Something like add a hello world function to the main file, to see the approval flow once
Write a single deny rule. Before widening the automation, put what must not be touched into permissions.deny in .claude/settings.json — see Design permissions in Claude Code's settings.json
Look at your usage. /usage shows how much of your plan you are consuming; Check Claude Code usage and cost covers the rest

The commands worth memorizing:

Command	What it does
`claude`	Start interactive mode
`claude "task"`	Start with an initial prompt
`claude -p "query"`	Run one query, then exit
`claude -c`	Continue the most recent conversation in this directory
`claude -r`	Resume a previous conversation
`/help`	Show available commands
`/clear`	Clear conversation history
`/login`	Switch accounts or re-authenticate

Summary

Requirements: macOS 13.0+, Windows 10 1809+, Ubuntu 20.04+ and similar, with 4 GB+ RAM
The free claude.ai plan does not include Claude Code; you need Pro, Max, Team, Enterprise, Console or a cloud provider
Pick the install method by auto-update behavior: native and npm update themselves, Homebrew, WinGet, apt, dnf and apk do not
Verify with claude --version, and read claude doctor when something is off
On Windows, sandboxing means WSL 2; native Windows and WSL 1 do not support it
In the first hour: check the permission mode, run /init, send one small change, then write a deny rule

Codex CLI v0.161 and v0.162 changes, and GPT-6.1 Sol becoming the default model

aicoding-guide — Sun, 11 Oct 2026 19:13:42 +0000

Originally published at https://aicoding-guide.com.

Codex CLI v0.161.0 and v0.162.0 carry two changes that reach into your configuration: the default model was swapped and the way Daybreak is enabled changed.

Two things are worth checking because of them: whether you pin a model in config.toml, and whether you have added the cli_daybreak opt-in if you use Daybreak.

Setting keys below are only the ones confirmed against the official configuration reference as fetched on 2026-10-12; anything unconfirmed is marked as such.

Key point
What you will learn

Where GPT-6.1 Sol became the default, and how to pin a model yourself

That Daybreak now requires an explicit opt-in

The approval and sandbox changes, and where the worktree tools stand

GPT-6.1 Sol is the new default model

The v0.161.0 release notes read "GPT-6.1 Sol is now the default model in the bundled and Amazon Bedrock catalogs." What is stated as default is the bundled catalog and the Amazon Bedrock catalog; other setups are not addressed.

The model row in the configuration reference now uses gpt-6.1-sol as its example:

Key	Type	Description
`model`	`string`	Model to use (e.g., `gpt-6.1-sol`)

To pin it instead of taking the default, put it at the top level of ~/.codex/config.toml:

model = "gpt-6.1-sol"

Check availability on your account first
The reference says to "Set model to one available to your signed-in account or workspace," and tells you to check GPT-6.1 Sol availability before using that example value. If your organization's workspace doesn't offer it, writing it into model won't make it work.

Amazon Bedrock also gained multi-agent V2 and Ultra reasoning support. For setting reasoning depth, see Change the reasoning effort in Codex.

Daybreak needs an explicit opt-in

This is the change most likely to break an existing setup. The release notes read: "Daybreak is opt-in through --enable cli_daybreak or features.cli_daybreak=true; daybreak=true alone is insufficient."

# v0.161.0 and later. daybreak = true on its own does nothing
[features]
cli_daybreak = true

By default the controls and indicators are hidden and /daybreak is unavailable — and automatic Cyber routing is omitted even for saved Daybreak threads. Saved preferences themselves remain intact, so adding cli_daybreak restores the previous state. codex exec --cyber-access-program was also added for choosing a Cyber access program per turn; that override stays available with cli_daybreak disabled.

features.cli_daybreak is not in the configuration reference
As of 2026-10-12 there is no cli_daybreak row in the official reference's features.* table. The key name appears only in the release notes. The rows that are listed include features.apps, features.hooks, features.memories, features.multi_agent and features.network_proxy.

For config.toml as a whole, see What you can configure in Codex's config.toml.

Approval and sandbox changes

Permissions got fixes in both releases.

Approved escalation: approved filesystem escalation can now grant broader write access while preserving denied reads and network restrictions. Background tasks retain their originating turn's permissions
Linux sandbox: startup with multiple denied files is fixed, and writable sandbox-construction executables are now rejected
ripgrep config: ripgrep configuration no longer weakens deny-glob masks. Paths you were protecting with a deny rule may have been visible to search, so this is worth upgrading for if you exclude sensitive files in the sandbox
Windows: elevated terminal sessions can start using an embedded server, and ordinary drive-letter file access is restored on Windows 10

For the approval policy and sandbox settings themselves, see Codex approval policy and sandbox settings.

Worktree tools, the TUI, and the rest

In v0.162.0, when the worktrees feature is enabled, there are tools for creating and listing managed Git worktrees from trusted local projects. The key that enables that feature could not be confirmed in the official configuration reference.

In the TUI: /copy navigates and copies transcript blocks, Ctrl+Insert copies a selection, mouse-wheel speed is tunable (the release notes name tui.mouse_scroll_speed, which likewise does not appear in the reference's tui.* table), and URLs are clickable in approval headers, questions, MCP prompts, warnings and banners, including across wrapped lines.

The rest, as it touches configuration and operations:

Version	Change
0.160.1	Preserves `SYSTEMROOT`, `TEMP` and `TMP` when launching remote stdio MCP servers
0.161.0	`/mcp login <name>` signs in to an MCP server from an active session
0.162.0	`apply_patch` preserves existing CRLF line endings without an opt-in; Windows releases ship a signed PowerShell installer
0.162.1	Fixes a TUI crash on multi-line asynchronous questions, and startup failures from feature-setting differences between a running background server and CLI defaults

For adding MCP servers, see Set up MCP servers in Codex; for the previous release, Codex CLI v0.160 changes.

Summary

v0.161.0 makes GPT-6.1 Sol the default in the bundled and Amazon Bedrock catalogs; confirm separately that your account can use it
To pin a model, set model = "gpt-6.1-sol" at the top level of config.toml
Daybreak needs --enable cli_daybreak or features.cli_daybreak = true; daybreak = true alone does nothing
ripgrep configuration no longer weakens deny-glob masks — worth upgrading for if the sandbox excludes sensitive files
features.cli_daybreak, the worktrees feature flag and tui.mouse_scroll_speed are all absent from the official configuration reference's tables

Claude Code permissions by example, auto-allow npm scripts, confirm git push, block force push

aicoding-guide — Sat, 10 Oct 2026 23:16:31 +0000

Originally published at https://aicoding-guide.com.

When you let Claude Code drive, you usually want three lines drawn. Scripts you wrote yourself, such as npm run lint and npm run test, should run without a prompt. git push reaches the remote, so you want one last look right before it. git push --force should never run at all.

All three fit in a single permissions block in settings.json, using the three layers allow, ask and deny. This article shows the finished configuration first, then explains each layer and the places people trip.

Key point
What you will learn

A complete settings.json that combines allow, ask and deny

What the :* prefix match means, and how to keep install commands out of an allow rule

Why ask outranks allow, and why "don't ask again" still prompts

How to cover every spelling of a force push (-f, --force-with-lease, reordered options) with deny

The finished configuration

Put this in the project's .claude/settings.json. It is written to be shared with a team.

{
  "permissions": {
    "allow": [
      "Bash(npm run:*)",
      "Bash(npm test)",
      "Bash(npx tsc:*)",
      "Bash(npx vitest:*)",
      "Bash(npx eslint:*)",
      "Bash(npx prettier:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm install:*)",
      "Bash(npm i:*)",
      "Bash(npm uninstall:*)"
    ],
    "deny": [
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git push --force-with-lease:*)",
      "Bash(git push * --force:*)"
    ]
  }
}

With this in place, scripts and the read-only Git commands plus commits run silently, git push and npm install open a dialog, and a force push is refused.

Glossary
Rule precedence: rules are evaluated deny, then ask, then allow, and the first match in that order decides. Specificity does not change the order. An allow rule for Bash(git:*) does not stop an ask rule for Bash(git push:*) from prompting, and a deny match is refused in every permission mode.

1. Auto-allow npm scripts (allow)

In Bash(npm run:*), :* is a prefix match: "starts with npm run, anything may follow." It matches arguments too, such as npm run test -- --watch. npm install begins differently, so it is not swept in. Put the * after the subcommand; a rule with the * before it, like Bash(npm * test), triggers a startup warning.

npx can run any package, so the example allows only the ones you use rather than the whole program. Do not put Bash(npx:*) in ask: ask is evaluated before allow, so the npx tsc you just allowed would start prompting too. Leaving it out means "the ones I allowed run silently, any other npx follows the default behavior."

Patterns per package manager

Tool	Running scripts	Install commands (ask)
npm	`Bash(npm run:*)`	`Bash(npm install:)`, `Bash(npm i:)`
pnpm	`Bash(pnpm run:*)`, `Bash(pnpm test)`, `Bash(pnpm lint)`	`Bash(pnpm add:)`, `Bash(pnpm install:)`
yarn	`Bash(yarn run:*)`, `Bash(yarn test)`	`Bash(yarn add:*)`, `Bash(yarn install)`
bun	`Bash(bun run:*)`	`Bash(bun add:)`, `Bash(bun install:)`

pnpm and yarn let you drop run, as in pnpm lint, so either list the scripts you use or allow the whole program and stop the install commands with ask rules. Because ask is evaluated first, that combination is safe:

{
  "permissions": {
    "allow": ["Bash(pnpm:*)"],
    "ask": ["Bash(pnpm add:*)", "Bash(pnpm install:*)", "Bash(pnpm remove:*)"]
  }
}

For a Python project

{
  "permissions": {
    "allow": ["Bash(pytest:*)", "Bash(python -m pytest:*)", "Bash(ruff:*)", "Bash(mypy:*)", "Bash(uv run:*)"],
    "ask": ["Bash(pip install:*)", "Bash(uv add:*)"]
  }
}

2. Confirm every git push (ask)

An ask rule means "prompt me even if an allow rule matches." Automate the read-only Git commands and commits with allow, put Bash(git push:*) in ask, and only the push stops.

The dialog at push time offers these options:

Option	Effect
Allow once	Runs this one call
Don't ask again	Appends an allow rule to `settings.local.json`, but you are still prompted next time while the ask rule remains
Deny	Does not run, and lets you tell Claude why

That "don't ask again" leaves the ask rule in place is intended. It keeps you from undoing "I always review pushes" with one keystroke. To stop the prompts, remove the ask line from the settings file.

Auto-allowing one branch only

If pushes to your own working branches should go through, scope both the allow and the ask rule by branch:

{
  "permissions": {
    "allow": ["Bash(git push origin feature/*:*)"],
    "ask": ["Bash(git push origin main:*)", "Bash(git push origin develop:*)"]
  }
}

This depends on Claude spelling the command as git push origin feature/xxx. A bare git push matches neither rule and falls through to your defaultMode. If you value reliability over convenience, skip the branch scoping and keep one "always confirm pushes" rule.

3. Block force push (deny)

Deny is evaluated before ask and allow, and it applies in every permission mode, including bypassPermissions, where allow rules have no effect. A deny in the project's settings.json cannot be undone by an allow in someone's settings.local.json, which is why team-wide prohibitions belong here.

Bash rules match the command text, so each spelling needs its own line:

Command	Pattern that matches it
`git push --force origin main`	`Bash(git push --force:*)`
`git push -f origin main`	`Bash(git push -f:*)`
`git push origin main --force`	`Bash(git push * --force:*)`
`git push --force-with-lease`	`Bash(git push --force-with-lease:*)`

--force-with-lease is safer than a bare --force, but it still overwrites the remote. If your team allows it, move that one line into ask.

A deny rule is a safety net, not a wall
cd repo && git push --force, or a push buried in a shell script, does not start with the text your rule matches. For a branch that genuinely must not be rewritten, set branch protection on the remote (GitHub's "do not allow force pushes") and treat the deny rule as a way to reduce local accidents.

The same approach covers other commands that destroy work:

{
  "permissions": {
    "deny": ["Bash(git reset --hard:*)", "Bash(git checkout -- .:*)", "Bash(git clean -f:*)"]
  }
}

Verify it

Save the settings and restart Claude Code.
Run /permissions and check that each list shows the lines you wrote and the file each came from.
Say "run the tests." If npm run test goes without a prompt, allow works.
Say "add lodash." If npm install lodash prompts, ask works.
Say "commit this and push it." The commit should go through and a dialog should appear right before the push.
Ask Claude to run git push --force origin test-branch. It should be refused.

Related settings

How settings.json and settings.local.json divide the work, how the scopes override each other and how to pick a defaultMode are covered in the parent article, Claude Code permissions in settings.json and settings.local.json. For the file-oriented version of the same mechanism, see Stop Claude Code reading your .env. Once scripts run unattended, a hook that lints after every edit keeps quality up: Run lint and format automatically with Claude Code hooks.

Summary

Rules are evaluated deny, then ask, then allow, and the first match decides
Bash(npm run:*) allows every npm script in one rule; npm install is a different prefix. When allowing a whole program such as pnpm or npx, stop the install commands with ask
Bash(git push:*) in ask forces a prompt right before every push, and "don't ask again" does not remove it
Deny --force, -f, --force-with-lease and the reordered form separately. Deny applies in every mode and cannot be undone by personal settings
Pair the deny rules with branch protection on the remote for anything you cannot lose

This week in Claude Code, Codex and Gemini CLI (week of October 11, 2026)

aicoding-guide — Sat, 10 Oct 2026 19:13:13 +0000

Originally published at https://aicoding-guide.com.

The change with the widest reach this week is Claude Haiku 5.5. It is now the default Haiku model on the Anthropic API, with a 1M-token context, and short prompts cost a tenth of what Haiku 4.5 did. On the Codex side, the default model is now GPT-6.1 Sol.

Claude Code also landed several fixes for permission rules that were being skipped. If you lean on the sandbox or on hooks to make permission decisions, this is a week to update early.

Key point
This week's highlights

Claude Haiku 5.5 is the default Haiku on the API (1M context, $0.10 / $0.50)

Claude Code fixed Bash deny and ask rules being skipped, and a permission bypass for UNC-path file reads

Codex's default model is GPT-6.1 Sol, and Daybreak now needs an explicit opt-in

Claude Code

Claude Haiku 5.5 arrives (2.1.293)

claude-haiku-5-5 was added and is now the default Haiku model on the Anthropic API. The CHANGELOG reads "1M context, $0.10/$0.50 per Mtok ($0.50/$2.50 for prompts over 100K)", and the official pricing page fetched on 2026-10-11 has the same split.

Model	Input (per Mtok)	Output (per Mtok)
Claude Haiku 5.5 (prompts up to 100K)	$0.10	$0.50
Claude Haiku 5.5 (prompts over 100K)	$0.50	$2.50
Claude Haiku 4.5	$1	$5

A tenth of Haiku 4.5 on short prompts — but the rate is 5x higher once you pass 100,000 tokens.

Several permission rules were being skipped (2.1.289, 2.1.292)

A cluster of fixes landed for the category "the thing you thought your settings blocked went through anyway."

When the sandbox auto-allows commands, a Bash command with an environment-variable prefix such as TZ="$HOME" rm -rf build did not match deny or ask rules. The same held for a bare variable assignment before the command
Read deny rules did not apply to files @-mentioned or selected in the IDE through a symlink
Security: PreToolUse hook approvals and auto mode bypassed the permission prompt for file reads from network (UNC) paths
A notebook or PDF read on macOS and Windows could return a file outside what was approved, through a link swapped in mid-read

Designing deny rules is covered in Design permissions in Claude Code's settings.json — though this week is also a run of examples showing that having written the rule is not itself the guarantee.

onFailure blocks the action when a hook fails (2.1.295)

Command and HTTP hooks take onFailure: "block". A hook that can't start, times out, or exits with an unexpected code now blocks the action instead of letting it through.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "bash .claude/hooks/check.sh", "onFailure": "block" }
        ]
      }
    ]
  }
}

If you use hooks as enforcement rather than as a request, a broken hook used to mean the action sailed past. 2.1.294 also fixed prompt and agent hooks written as instructions allowing what they should block.

New settings around subagents (2.1.290, 2.1.292, 2.1.296)

What was added	What it does
`effort` on the Agent tool	Runs a subagent at the effort level you ask for
`autoCompactWindow` in subagent frontmatter	Lets a subagent auto-compact earlier than the main conversation (also in `--agents` definitions)
`CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL`	Runs every workflow agent on one model while other subagents keep theirs
`allow_large` on the Read tool	Reads a text file past the usual size limits in one call

See Create subagents in Claude Code for the rest. CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS and ..._MAX_DELAY_MS were also added, to lengthen the backoff when retrying an overloaded (529) request.

2.1.290 additionally fixed WebFetch silently dropping page text past 100,000 characters; it now says how much was unread and takes an offset to read on.

Codex

The default model is now GPT-6.1 Sol (0.161.0)

The release notes read "GPT-6.1 Sol is now the default model in the bundled and Amazon Bedrock catalogs." What is stated as default is the bundled catalog and the Amazon Bedrock catalog; other setups are not addressed. /mcp login <name> also arrived, for signing in to MCP servers from an active terminal session.

Daybreak needs an explicit opt-in (0.161.0)

daybreak=true on its own is not enough. You need --enable cli_daybreak or features.cli_daybreak=true. By default the controls and indicators are hidden and /daybreak is unavailable; saved preferences themselves remain intact. For writing config.toml, see What you can configure in Codex's config.toml.

Worktree tools and TUI changes (0.162.0)

With the worktrees feature enabled, there are now tools for creating and listing managed Git worktrees from trusted local projects. apply_patch preserves existing CRLF line endings without an opt-in. In the TUI, /copy navigates and copies transcript blocks, and tui.mouse_scroll_speed tunes mouse-wheel scrolling.

Sandbox fixes (0.161.0, 0.162.0)

Approved filesystem escalation can now grant broader write access while preserving denied reads and network restrictions, and background tasks retain their originating turn's permissions. 0.162.0 fixed Linux sandbox startup with multiple denied files and stopped ripgrep configuration from weakening deny-glob masks.

Gemini CLI

v0.63.0 is 15 fixes with no new features and no new setting keys. The two that matter: the removal of what caused cannot spawn : No such file or directory during diffs (Gemini CLI was overriding Git's diff.external with an empty string), and the fix for a negative tools.truncateToolOutputThreshold roughly doubling output instead of disabling truncation. Details in Gemini CLI v0.63 changes.

What to check now

Move Claude Code to 2.1.296 or later — every permission-bypass fix this week is in that range
If you rely on Bash deny or ask rules under sandbox auto-allow, test a command with an environment-variable prefix and confirm it still stops
If you use hooks as enforcement, add onFailure: "block" to them
Review the model id where you use Haiku and move to claude-haiku-5-5, noting the 5x rate above 100,000 tokens
If you were using Daybreak in Codex, switch to --enable cli_daybreak or features.cli_daybreak=true

Summary

Claude Haiku 5.5 is the default Haiku on the API: 1M context, $0.10 / $0.50 up to 100K tokens
Claude Code 2.1.289 to 2.1.292 concentrate the fixes for skipped permission rules; the UNC-path read is marked Security
onFailure: "block" stops the action when a hook itself fails
Codex defaults to GPT-6.1 Sol in the bundled and Bedrock catalogs, and Daybreak needs the cli_daybreak opt-in
Gemini CLI v0.63.0 is fixes only

Auto-allow npm scripts in Claude Code without allowing npm install

aicoding-guide — Fri, 09 Oct 2026 19:22:46 +0000

Originally published at https://aicoding-guide.com.

A confirmation dialog on every npm run lint, npm run test and npm run build is the single biggest drag on working with Claude Code. The scripts in your package.json are commands you wrote yourself, so there is no reason not to allow them as a group.

In short: put Bash(npm run:*) in allow and every npm script stops prompting. npm install is a different prefix, so it is not swept in by accident.

Key point
What you will learn

Patterns that allow scripts for npm, pnpm, yarn and npx

What :* means, and how to keep install commands out of the rule

The equivalent for Python projects (pytest, ruff)

The setting

{
  "permissions": {
    "allow": [
      "Bash(npm run:*)",
      "Bash(npm test)",
      "Bash(npx tsc:*)",
      "Bash(npx vitest:*)",
      "Bash(npx eslint:*)",
      "Bash(npx prettier:*)"
    ],
    "ask": [
      "Bash(npm install:*)",
      "Bash(npm i:*)",
      "Bash(npm uninstall:*)"
    ]
  }
}

npx can run any package, so this allows only the ones you use rather than the whole program. Note that npx is deliberately not in ask: an ask rule prompts even when a more specific allow rule also matches, so Bash(npx:*) in ask would start prompting for the npx tsc you just allowed. Leaving it out means "the ones I allowed run silently, any other npx follows the default behavior" — a prompt in Manual mode.

Glossary
What :* means: Bash(npm run:*) is a prefix match — "starts with npm run, anything may follow." It matches arguments too, such as npm run test -- --watch. Put the * after the subcommand; a rule with a * before it, like Bash(npm * test), triggers a startup warning.

Patterns per package manager

Tool	Running scripts	Install commands (ask)
npm	`Bash(npm run:*)`	`Bash(npm install:)`, `Bash(npm i:)`
pnpm	`Bash(pnpm run:*)`, `Bash(pnpm test)`, `Bash(pnpm lint)`	`Bash(pnpm add:)`, `Bash(pnpm install:)`
yarn	`Bash(yarn run:*)`, `Bash(yarn test)`	`Bash(yarn add:*)`, `Bash(yarn install)`
bun	`Bash(bun run:*)`	`Bash(bun add:)`, `Bash(bun install:)`

pnpm and yarn let you drop run, as in pnpm lint, so either list the scripts you use individually or allow the whole program and stop the install commands with ask rules. Because ask is evaluated before allow, that combination is safe:

{
  "permissions": {
    "allow": ["Bash(pnpm:*)"],
    "ask": ["Bash(pnpm add:*)", "Bash(pnpm install:*)", "Bash(pnpm remove:*)"]
  }
}

For a Python project

{
  "permissions": {
    "allow": [
      "Bash(pytest:*)",
      "Bash(python -m pytest:*)",
      "Bash(ruff:*)",
      "Bash(mypy:*)",
      "Bash(uv run:*)"
    ],
    "ask": [
      "Bash(pip install:*)",
      "Bash(uv add:*)"
    ]
  }
}

Verify it

Save the setting and restart Claude Code.
Open /permissions and check the allow list.
Say "run the tests." If npm run test goes without a prompt, it works.
Say "add lodash." If npm install lodash prompts, the ask rules work too.

Related settings

Once the scripts run unattended, a hook that always lints after an edit keeps quality up as you widen the automation — see Run lint and format on save with Claude Code hooks. For the overall design, see the parent article, Design permissions in Claude Code's settings.json.

Summary

Bash(npm run:*) allows every npm script in one rule, and npm install is a different prefix so it stays out
When allowing a whole program such as pnpm or npx, stop the install commands with ask rules — ask is evaluated before allow
For Python, allow pytest, ruff and uv run, and put pip install in ask

Make a coding agent write the failing test before the implementation

aicoding-guide — Fri, 09 Oct 2026 19:22:45 +0000

Originally published at https://aicoding-guide.com.

Ask a coding agent to "implement this feature" and the implementation arrives fast, but the verification often ends at "it should work." The most effective fix is to make it write a failing test first, confirm the failure, and only then implement.

An agent with a concrete goal — "make this test pass" — can iterate on its own. This article covers the prompts that work across all three tools, and the tool-specific ways to enforce the rule rather than request it.

Key point
What you will learn

The four steps of the workflow and the prompt for each

What to put in your context file (CLAUDE.md / AGENTS.md / GEMINI.md)

How to stop the agent from editing the tests, and what to do when it goes wrong

The four steps

Step	What happens	What to tell the agent
1. Write the test	A failing test derived from the spec	Say "don't write the implementation yet"
2. Confirm the failure	Run it and see it fail	Have it confirm the failure is "not implemented"
3. Implement	Change the implementation until the test passes	Say "don't change the test"
4. Tidy up	Remove duplication, improve names, add cases	Have it confirm tests still pass afterwards

The important part is that steps 1 and 3 are separate instructions. Roll them into one ("write tests and implement it") and the agent tends to write the implementation first and back-fill a test that fits it.

The prompts

Step 1: tests only

I want a calculateTotal function in `src/lib/pricing.ts` that returns the discounted
total from a quantity and a unit price.
Spec:
- 5% off at 10 or more, 10% off at 100 or more
- Throw if the quantity is 0 or less
- Round fractions down

First, write only the tests for this spec in `src/lib/pricing.test.ts`.
Do not write the implementation yet. Once the tests are written, run
`pnpm test pricing`, confirm they all fail because the function does not exist,
and report back.

Steps 2–3: implement

Implement calculateTotal so every test in pricing.test.ts passes.
Do not modify the test file. If you think a test is wrong, report why
without changing it.
Run `pnpm test pricing` afterwards and paste the result.

Step 4: tidy up

Review the implementation and the tests, and clean up duplication or unclear names.
Add boundary cases if any are missing (9, 10, 99, 100).
Finally run `pnpm test pricing` and `pnpm lint` and report the results.

Glossary
Boundary cases: tests at the points where the spec changes behavior (10, 100) and just either side of them (9, 11). Agents tend to test "representative" values only, so asking for boundaries explicitly pays off.

Put it in the context file

If repeating the instructions gets tiring, write the workflow into your context file. The same text works for all three tools:

## How to implement (test first)
1. For a new feature or a fix, write a failing test first and run it to confirm the failure
2. Implement until the test passes. Do not change the test file while implementing
3. If you judge a test to be wrong, report why without changing it and wait for instructions
4. Include the test command you ran and its result (passed / failed counts) in your report
5. If there is no test setup, propose setting one up first

For keeping one copy of that text across the three files, see CLAUDE.md, AGENTS.md and GEMINI.md differ only in how they load.

Claude Code: enforce it with a hook

In Claude Code you can make this a mechanism rather than a request. The documentation is explicit that a context file is "context, not enforced configuration" and points at a PreToolUse hook to block an action regardless of what Claude decides.

A hook that blocks edits to test files during the implementation phase:

#!/usr/bin/env bash
# .claude/hooks/protect-tests.sh
# Only blocks test-file edits when PROTECT_TESTS=1
[ "${PROTECT_TESTS:-0}" = "1" ] || exit 0
file=$(jq -r '.tool_input.file_path // empty')
case "$file" in
  *.test.*|*.spec.*|*/__tests__/*)
    echo "Test files can't be changed during the implementation phase: $file. If a test is wrong, report why." >&2
    exit 2 ;;
esac
exit 0

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write|NotebookEdit",
        "hooks": [{ "type": "command", "command": "bash .claude/hooks/protect-tests.sh" }]
      }
    ]
  }
}

Exit code 2 on PreToolUse blocks the tool call, so starting with PROTECT_TESTS=1 claude makes tampering with the tests physically impossible rather than merely discouraged. For hook basics, see Run lint and format on save with Claude Code hooks.

Fix the procedure in a skill: writing the four steps into a /tdd <spec> slash command keeps every run on the same track (Create your own slash commands). Delegating the test run to a subagent keeps long test output out of your main context.

Codex and Gemini CLI

Neither has an equivalent of hooks, so you run this on instructions plus inspection.

Codex: keep the implementation phase on --sandbox workspace-write, and check with /diff that the test files are unchanged before you approve. Put the workflow in AGENTS.md.
Gemini CLI: turn checkpointing on, and if a test file was modified, roll back with /restore. Put the workflow in GEMINI.md.

When it goes wrong

Symptom	What to do
It writes the implementation during the test step	Repeat "don't write the implementation yet" at the end of the prompt too. In Claude Code, use plan mode to get a plan only
It loosens the test when it won't pass	State "don't change the test" and block it with a hook
The tests are all mocks and prove nothing	Say "mock external dependencies if you must, but never mock the logic of the function under test"
The test run takes too long	Put a narrowing command in the prompt (`pnpm test pricing`)

Summary

Make "write the test" and "implement" separate instructions, with a confirmed failure in between
State "don't change the test file" and "include test results in your report" every time, or put them in your context file
Claude Code can block test-file edits with a PreToolUse hook and fix the procedure in a skill
With Codex and Gemini CLI, use /diff or checkpointing to check the tests weren't tampered with