Bash Exit Code 127: A Regression, a Same-Day Patch
Exit code 127 is the POSIX shell convention for "command not found." In v2.1.147, a regression caused the Bash tool to return 127 on every invocation — not only when the target binary was missing, but regardless of what the command was doing . Anthropic shipped v2.1.148 as a single-change hotfix on the same day the regression was identified, isolating the fix rather than bundling it with the next content drop. The decision to issue a dedicated point release signals that tool execution integrity is treated as a blocking concern — not something that waits for the next content cycle.
The blast radius matters here. Bash is the most-invoked tool across agentic task flows in Claude Code: test runs, file reads, build pipelines, package installs, and conditional logic all route through it. When the tool returns 127, the model interprets the result as "command not found" and may take a recovery path — retrying with a different binary path, attempting to install missing tooling, or abandoning the step entirely. None of those paths is correct when the underlying command ran fine; they produce semantically wrong behavior with no surface-level error signal pointing to the real cause.
"Fixed Bash tool incorrectly returning exit code 127 (command not found) — a regression from the previous version." — Claude Code Changelog, v2.1.148
The single-change hotfix approach also benefits operators on pinned-version deployments. The upgrade target is unambiguous: bump to v2.1.148, nothing else changes. If the fix had been bundled alongside new features, operators would have had to absorb unrelated changes to close a regression — a tradeoff Claude Code's release process explicitly avoids for tool execution bugs.
If your environment ran automated pipelines during the v2.1.147 window , audit task logs for unexpected 127 returns that triggered fallback branches. Any remediation code that executed in response to false command-not-found errors — retries, alternative install paths, skip-step logic — should be reviewed. Successful outputs from this window are trustworthy; recovery-path outputs are not.
Four Permission-Layer Security Fixes in v2.1.149
The second release of May 22, v2.1.149, addressed four vulnerabilities in Claude Code's Bash and PowerShell permission layer, all sharing a common pattern: the rule engine checked commands at invocation, but alternative invocation forms and shell state variables were not subject to the same checks . Together they represent meaningful bypass surface through which a script inside an agentic session could change the working directory or invoke executables outside the boundaries the operator's allow rules were intended to enforce. A separate macOS-specific fix also addressed a case where find on large directory trees could exhaust the system vnode table — detailed in the Claude Code official changelog.
| Vulnerability | Component | Attack Vector | Fix Applied |
|---|---|---|---|
| cd bypass | Bash / PowerShell | cd.., cd\, cd~, X: (Windows drive-letter) changed directory without triggering allow-rule detection |
All alternative cd forms now matched against allow rules before execution |
| Git-worktree sandbox misconfiguration | Git integration | Shared .git directory boundary set to full repo root — all tracked files accessible instead of only git internals |
Boundary corrected to expose only the .git internals directory |
| Prefix / wildcard allow-rule gap | Permission layer | Native executables covered by wildcard rules still required explicit re-approval at invocation time | Wildcard rules now pre-approve matching native binaries without requiring explicit approval |
| PWD / OLDPWD / DIRSTACK tracking gap | Shell state tracker | pushd / popd sequences left the tracked working directory stale — scripts could walk outside permitted subtrees undetected |
Variable tracking extended to stay synchronized across cd, pushd, and popd |
macOS vnode exhaustion (find) |
macOS tool binding | find on large directory trees exhausted the system vnode table |
find invocations now bounded on macOS |
"Fixed multiple security issues: cd-bypass variants (cd.., cd\, cd~, X: drive-letter forms), git worktree sandbox misconfiguration exposing the full repo root, wildcard allow-rules not pre-approving native executables, and PWD/OLDPWD/DIRSTACK tracking across pushd/popd sequences." — Claude Code Changelog, v2.1.149
The cd bypass is the most broadly applicable of the four. On Windows, drive-letter prefixes (C:, D:) are valid alternatives to cd C:\; on Unix, cd.. without a space is parsed by some shells. If your allow rules use path-prefix matching, a script could have traversed to an out-of-scope directory using an unrecognized invocation form, operated there without triggering a re-check, and then returned — leaving no trace in the permission audit trail that a boundary had been crossed .
The git-worktree misconfiguration deserves separate attention for teams using worktrees as lightweight workspace isolation. The intent of the sandbox is to restrict the agent to the working tree while keeping the full repository root — config files, hooks, credentials, and commit history under .git/ — outside the accessible boundary. The misconfiguration inverted this: the boundary was set to the repo root rather than the .git directory itself. Any agent session using a git-worktree sandbox between v2.1.147 and v2.1.149 had broader filesystem access than the operator intended.
The PWD/OLDPWD/DIRSTACK gap is a time-of-check versus time-of-use inconsistency in sandbox enforcement. When a script calls pushd /allowed/path followed by popd, the tracker must update on every state transition. If it failed to update on popd, the tracker could show a permitted path while the shell's actual current directory had drifted elsewhere. The fix keeps the tracker synchronized with the shell's own directory stack at all times.
/code-review --fix: From Suggestions to Direct File Edits
/code-review --fix, introduced in v2.1.152 , changes the command from an advisory tool into a direct editor. Before this release, /code-review analyzed the working tree for reuse opportunities, simplification candidates, and efficiency gaps, then printed findings as text — the developer applied changes manually. With --fix, the analysis and the edits happen in a single pass: findings are written to the working tree immediately, with no separate confirmation step and no diff preview before writes.
"Reuse, simplification, and efficiency" findings have specific meanings in Claude Code's analysis pass. Reuse findings identify duplicated logic that could be extracted into a shared function or constant. Simplification findings target unnecessarily complex expressions, redundant conditions, or verbose patterns that carry no semantic benefit. Efficiency findings cover structural issues — unnecessary loops, repeated lookups that could be cached, data transformations that could be combined. With --fix, all three categories are applied simultaneously in a single working-tree mutation.
"
/code-review --fixnow applies reuse, simplification, and efficiency findings directly to the working tree./simplifyhas been updated to invoke/code-review --fixinternally — both commands now produce identical edits." — Claude Code Releases, v2.1.152
The /simplify rewiring is the most consequential behavioral change for developers who use it routinely. Before v2.1.152, /simplify and /code-review --fix were separate command paths with separate implementations. As of v2.1.152, /simplify calls /code-review --fix under the hood. If you treated /simplify as advisory — running it to see suggestions and deciding what to apply — that workflow no longer holds. Both commands now mutate files on invocation.
Auto-formatted or generated code deserves particular attention. Simplification heuristics and formatter rules can conflict: a heuristic that collapses a multi-line expression may violate a project's configured line-length constraint, leaving the codebase in a state that fails gofmt, prettier, or black on the next CI pass. The safest workflow: run /code-review --fix or /simplify, immediately run your formatter, then inspect the combined diff before staging. Running /code-review without --fix still produces advisory-only output — the default behavior is unchanged for developers who need to review suggestions before deciding what to apply.
For projects with CI-enforced style checks, a pre-commit hook that re-runs the formatter after any Claude Code session reduces the risk of simplification edits landing in a pull request that fails lint on the first check. This pattern also produces coherent commit history: the simplification edit and the formatter correction are staged together, making bisection straightforward if a style regression surfaces later.
