Claude Code v2.1.152 - Detailed Explanation of `/code-review --fix` (Applying to the Working Tree)

I'm Ishikawa from the Cloud Business Division. In my recent post on the major updates in Claude Code v2.1.152, I introduced that /code-review --fix now applies review results directly to the working tree, and that /simplify now calls /code-review --fix. Since the built-in /code-review is something I rely on all the time, I prepared sample code and tried it out while also checking its previous behavior.

https://dev.classmethod.jp/articles/20260524-claude-code-updates-v2-1-152/

In this article, I prepare sample code that deliberately has room for "reuse and simplification," check the findings with /code-review, and then see how /code-review --fix and /simplify actually apply fixes to the working tree.

Note that what we deal with here is the built-in /code-review, which reviews the current working diff. It is different from the plugin version of code-review, which reviews a GitHub PR and posts comments. The plugin version writes review results as comments on an existing PR, whereas the built-in version in this article targets the local working diff and even applies fixes.

What changed in this update

The changes listed in the CHANGELOG (v2.1.152) are the following two points.

• /code-review --fix now applies findings (suggestions for reuse, simplification, and efficiency) directly to the working tree after the review.
• /simplify now calls /code-review --fix.

/code-review itself is a command that points out "bugs (correctness)" and "cleanup for reuse, simplification, and efficiency" in the current diff, depending on the effort level. For outputting findings, there are --comment, which posts them as inline comments on a PR, and --fix, which applies them to the working tree. This update clarifies that --fix applies fixes directly to the working tree after the review.

What's good about it

• Review and applying fixes are completed with one command: With just --fix, you proceed from the review all the way to reflecting the findings in the working tree. It reduces the effort of reading the findings and reapplying them yourself.
• Covers cleanup, not just bugs: Not limited to correctness (bugs), it also picks up and applies refactoring-oriented findings such as code reuse (consolidating duplicates), simplification, and efficiency.
• Changes land in the working tree, so they're easy to check and pick and choose: Because changes go into the pre-commit working tree, you can safely try it out by checking the content with git diff and reverting anything unnecessary.
• Easy to call with /simplify: You can run "I want to tidy up the current diff overall" with the single word /simplify (under the hood it's /code-review --fix).
• Choose the depth with effort: You can use the effort level to distinguish between when you only want a few high-confidence findings and when you want a broad sweep (low / medium give few, high-confidence findings; high to max are broader; ultra is a multi-agent review in the cloud).

What is /code-review --fix?

/code-review is a command that points out the following aspects in the current diff.

• Bugs (correctness)
• Cleanup for reuse (consolidating duplicates), simplification, and efficiency

For outputting findings, there are --comment, which posts them as inline comments on a PR, and --fix, which applies them to the working tree. This update clarifies that --fix applies fixes directly to the working tree after the review.

The overall flow is as follows.

The relationship between the commands is as follows.

Trying it out

Prerequisites

• Claude Code 2.1.152
• macOS (Darwin 25.5.0)
• git 2.53.0 / Python 3.14.0
• Since /code-review targets the current git diff for review, prepare a git-managed repository and a diff to review.

1. Prepare a test repository and sample code

First, create a git repository and commit a straightforward implementation.

% git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"
Initialized empty Git repository in /Users/ishikawa.satoru/workspaces/cc/blog/20260528-code-review-fix/code-review-demo/.git/

Create cart.py, which just calculates a total amount, and commit it as the initial state.

"""買い物カゴの金額計算モジュール。"""

def calculate_total(items):
    total = 0
    for item in items:
        total += item["price"] * item["quantity"]
    return total

% git add cart.py && git commit -m "Add calculate_total for shopping cart"
[master (root-commit) 7c632a6] Add calculate_total for shopping cart
 1 file changed, 8 insertions(+)
 create mode 100644 cart.py

Next, as a diff to be reviewed, I add code that deliberately has room for "reuse and simplification." It includes a duplicate function that does almost the same thing as calculate_total, and redundant conditional branches using == True.

def calculate_subtotal(products):
    subtotal = 0
    for product in products:
        subtotal += product["price"] * product["quantity"]
    return subtotal

def is_premium_member(customer):
    if customer["is_premium"] == True:
        return True
    else:
        return False

def apply_discount(items, customer):
    total = calculate_total(items)
    if is_premium_member(customer) == True:
        return total * 0.9
    else:
        return total

The diff at this point is as follows.

% git diff
diff --git a/cart.py b/cart.py
index 6e3bd2a..4f305a2 100644
--- a/cart.py
+++ b/cart.py
@@ -6,3 +6,25 @@ def calculate_total(items):
     for item in items:
         total += item["price"] * item["quantity"]
     return total
+
+
+def calculate_subtotal(products):
+    subtotal = 0
+    for product in products:
+        subtotal += product["price"] * product["quantity"]
+    return subtotal
+
+
+def is_premium_member(customer):
+    if customer["is_premium"] == True:
+        return True
+    else:
+        return False
+
+
+def apply_discount(items, customer):
+    total = calculate_total(items)
+    if is_premium_member(customer) == True:
+        return total * 0.9
+    else:
+        return total

2. First, check only the findings with /code-review

Before applying anything, run /code-review without --fix to see what kind of findings come up.

/code-review

When I ran it, a review prompt was launched. At the maximum effort, you can tell that it is designed to review from multiple angles, including cleanup perspectives such as reuse, simplification, and efficiency in addition to correctness (bugs).

For this diff, the following findings were returned. Since --fix was not specified, the working tree is not changed at this stage.

• calculate_subtotal duplicates the same logic as calculate_total (reuse)
• Returning a boolean via if/else in is_premium_member is redundant (simplification)
• The == True comparison in apply_discount is redundant (simplification)

3. Apply to the working tree with /code-review --fix

Next, run it with --fix.

/code-review --fix

With --fix, a phase of "applying the findings to the working tree" was added at the end of the review prompt. The flow is that findings that would change behavior and false positives are skipped without being applied, and the results of the application are summarized at the end.

After applying, check what was changed with git diff. If you stage the pre-application state beforehand, you can isolate and check only the diff that --fix applied.

% git diff
diff --git a/cart.py b/cart.py
index 6e3bd2a..58d7e74 100644
--- a/cart.py
+++ b/cart.py
@@ -6,3 +6,18 @@ def calculate_total(items):
     for item in items:
         total += item["price"] * item["quantity"]
     return total
+
+
+def calculate_subtotal(products):
+    return calculate_total(products)
+
+
+def is_premium_member(customer):
+    return bool(customer.get("is_premium", False))
+
+
+def apply_discount(items, customer):
+    total = calculate_total(items)
+    if is_premium_member(customer):
+        return round(total * 0.9, 2)
+    return total

The duplicated calculate_subtotal was consolidated into a form that calls calculate_total, and the redundant if/else and == True in is_premium_member and apply_discount were also simplified.

Let's also confirm that the code after application isn't broken.

% python3 -c "
import cart
items = [{'price': 100, 'quantity': 2}, {'price': 50, 'quantity': 3}]
print('calculate_total   :', cart.calculate_total(items))
print('calculate_subtotal:', cart.calculate_subtotal(items))
print('discount(premium) :', cart.apply_discount(items, {'is_premium': True}))
print('discount(normal)  :', cart.apply_discount(items, {'is_premium': False}))
"
calculate_total   : 350
calculate_subtotal: 350
discount(premium) : 315.0
discount(normal)  : 350

calculate_subtotal returns 350, the same as calculate_total, and the discounts are also the expected values. The output matches before and after simplification, so the behavior has not changed.

4. Confirm that /simplify is an alias

I also check that /simplify is an alias of /code-review --fix. I add a new redundant function has_items and then run /simplify.

def has_items(items):
    if len(items) > 0:
        return True
    else:
        return False

/simplify

When I ran /simplify, the same review prompt (with the application phase) as when running /code-review --fix was launched. This confirms that it is an alias.

has_items was also simplified as follows.

% git diff
diff --git a/cart.py b/cart.py
index 6e3bd2a..778a9c4 100644
--- a/cart.py
+++ b/cart.py
@@ -6,3 +6,22 @@ def calculate_total(items):
     for item in items:
         total += item["price"] * item["quantity"]
     return total
+
+
+def calculate_subtotal(products):
+    return calculate_total(products)
+
+
+def is_premium_member(customer):
+    return bool(customer.get("is_premium", False))
+
+
+def apply_discount(items, customer):
+    total = calculate_total(items)
+    if is_premium_member(customer):
+        return round(total * 0.9, 2)
+    return total
+
+
+def has_items(items):
+    return len(items) > 0

Discussion

Here is a summary of what I learned from actually trying it.

• Review and application are completed with one command: With /code-review --fix alone, you go from identifying findings to reflecting them in the working tree. This time, instead of bugs, consolidating duplicates (reuse) and simplifying redundant conditional branches were applied.
• Changes land in the working tree, so they're easy to check and pick and choose: --fix rewrites the working tree but does not go as far as git add / commit. So you can check the content with git diff and revert unnecessary changes with git restore <file>. If you commit or stage the pre-application state beforehand, it's easier to isolate the diff that was applied.
• /simplify is identical to /code-review --fix: The prompts launched match, so you can run "I want to tidy up the current diff overall" with the single word /simplify.
• Choose the depth with effort: You can use effort (low / medium to high / max) to distinguish between when you only want high-confidence findings and when you want a broad sweep.

On the other hand, there are also points to be careful about.

• Findings are not necessarily the same every time: Since the review composes its findings according to the content of the diff, details may change from run to run even for the same code. After applying --fix, I recommend always checking the content with git diff.
• ultra is a separate track: /code-review ultra is a deep review by multiple agents in the cloud, and is a paid feature that the user must explicitly launch. Since its purpose differs from --fix, which automatically applies changes to the working tree, it is outside the scope of this article. Be careful not to confuse them.

Conclusion

I prepared sample code and actually tried /code-review --fix in Claude Code v2.1.152. I confirmed that the reuse and simplification findings from the review are applied directly to the working tree and can be checked with git diff, and that /simplify is an alias of the same thing.

Because changes go into the pre-commit working tree, you can check them with git diff and take in only what you need. If you routinely leave code review and refactoring to Claude Code, why not give it a try? I hope this article is helpful to someone.

References

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

https://code.claude.com/docs/en/changelog