@samwize

Customizing Claude Code Memory

Thu, 23 Apr 2026 19:10:00 +0800

Claude inject memories automatically in each session, and also retrieves memories whenever needed eg. troubleshooting. But you might wonder where are these memories kept?

The documentation explains well.

Here’s a tldr:

Auto memory is per-git-repo, machine-local
If not a repo, then keyed by the folder path
Default memory stored in ~/.claude/projects/<repo-or-path>/memory/
All worktrees/subdirs of same repo share one memory dir
Override with autoMemoryDirectory setting
Allowed in: user ~/.claude/settings.json, .claude/settings.local.json, managed policy
Blocked in: project .claude/settings.json (prevents malicious redirection)

Here’s a trick if you have multiple repos yet they are highly related hence you want a shared memory. You can point their project .claude/settings.local.json to same path! Symlinks also work as an alternative.

Codex Automations

Sat, 18 Apr 2026 16:05:00 +0800

Last month I wrote about how I kept Claude Code running forever with tmux, launchctl, and a resume prompt. That setup was ugly, but the model was simple: keep a session alive, or bring it back and tell it exactly how to continue.

Trying Codex automations made me realize the comparison is a bit subtler than I first thought.

The good part

The value still isn’t “automation” in the vague productivity-tool sense. It’s heartbeat. Some work should wake up every few minutes, look around, react, and go back to sleep. Monitoring Slack is one example. Reviewing PRs. Watching deploys. Orchestration, really.

That’s also why OpenClaw’s heartbeat became such a big deal. People don’t just want one-shot prompts anymore. They want agents that can keep an eye on things and wake themselves up when needed.

And Codex does make that easier. The app already has the scheduler. The Mac app can stay open on login. A pinned thread can wake up on cadence and keep working in the same conversation.

That makes using Codex Scheduler much easier.

What it actually is

Thread automations are described as recurring wake-up calls attached to a thread. That’s important. They preserve thread context, but they still wake up and run the same prompt again. In other words, this feels more like scheduled re-entry into the same thread than one continuously running local agent.

That may sound like a small distinction, but it changes how I think about it. My old Claude setup was clunky, but it was explicit. I knew where the restart logic lived. I knew when the session died. I knew what prompt brought it back. And most importantly, I knew the memories were local to Claude’s project.

Codex memories are more global, thus that might be mix in more context than necessary during the automation loop.

The pitfall

I also hit a dumb bug getting this to work. One thread refused to create the automation, citing no such scheduler tool. Then a new chat worked immediately.

Digging their sqlite, it seems the thread has the feature only during creation.

And you don’t need to pin the thread.

Claude Helped Spring Clean My Mac and Freed 90 GB

Tue, 14 Apr 2026 21:30:00 +0800

I wrote about cleaning Mac storage last year. That covered the basics: WhatsApp media, Xcode simulators, documentation cache.

But my storage filled up again. This time, instead of manually poking around folders, I ran Claude Code and asked it to help me find what’s eating my disk, feeding it with my instructions from the earlier blog post.

Your mileage will vary, every Mac accumulates different junk depending on what you use. But some of these discoveries were new to me, and I’ve been doing this for years.

I’ll hand it over to Claude from here to walk through what it found.

Claude here. The approach is the same du command from the original post, drilling down level by level:

du -h -d 1 ~/Library/ | grep "G\t" | sort -h

Find the heavy directories, run the same command one level deeper. Repeat until you hit the actual files. I just do it faster because I don’t get bored 5 levels deep into a path.

49 GB in 2 log files

The biggest find. Inside ~/Library/Logs/CoreSimulator/, two files:

File	Size
`CoreSimulator.prev.log`	35 GB
`CoreSimulator.log`	14 GB

Forty-nine gigabytes of simulator debug logs. Just sitting there. They’re safe to delete and get recreated automatically.

rm ~/Library/Logs/CoreSimulator/CoreSimulator*.log

If you’re an iOS developer who uses the simulator daily, check this folder. It might be your biggest win.

15 GB of dead containers

One simulator device was 21 GB. The app installed on it was nowhere near that big. Something was off.

I dug 5 levels deep and found com.apple.containermanagerd/Dead holding 15 GB. Every time you build and reinstall an app on the simulator, the old app container gets moved to this “Dead” folder. It never gets cleaned up.

The path is long:

~/Library/Developer/CoreSimulator/Devices/<UUID>/data/Library/Caches/com.apple.containermanagerd/Dead

Completely safe to delete. It’s orphaned data from previous installs.

iOS DeviceSupport (~5 GB per old version)

~/Library/Developer/Xcode/iOS DeviceSupport/ stores debug symbol caches that Xcode downloads when you connect a physical device. Each iOS version creates a new ~5 GB folder.

If you’ve updated your iPhone a few times, the old versions are just dead weight. Xcode re-downloads them if you ever connect a device running that specific version again. You can delete them from Xcode > Settings > Platforms, or just remove the folders directly.

Chrome’s hidden 4 GB model (per profile)

This one was genuinely surprising.

Each Chrome profile downloads a folder called OptGuideOnDeviceModel that contains a single weights.bin file. It’s 4 GB. It’s a Gemini Nano model that Chrome bundles for on-device AI features.

If you have 2 Chrome profiles, that’s 8 GB. Three profiles, 12 GB.

The annoying part: you can’t disable it. There’s no toggle in Chrome’s AI settings. And if you delete the folder, Chrome silently re-downloads it. So this one’s a known tax on your disk. Not actionable, just infuriating.

DerivedData (55 GB)

The classic one. ~/Library/Developer/Xcode/DerivedData/ is where Xcode stores build caches for every project. It’s safe to delete and Xcode rebuilds on demand.

rm -rf ~/Library/Developer/Xcode/DerivedData/*

We chose not to this time because all the projects were still active, and rebuilding a large production app is painful. But if you have stale projects in there, it’s worth clearing them out once in a while. 55 GB is a lot of disk for build artifacts.

Other quick wins

Outside of ~/Library/, I also scanned the home directory and found:

Ollama models (~/.ollama): 16 GB of local LLM models not touched in months. ollama list to check, ollama rm <name> to remove.
npm cache (~/.npm): 6 GB. npm cache clean --force to clear.
Homebrew cache: 3 GB. brew cleanup --prune=all to clear.

All safe. They re-download as needed.

What we chose NOT to delete

Knowing what not to delete is just as important.

SwiftPM cache (6 GB): Deleting means re-fetching every package dependency on next build.

Claude’s VM bundle (7.8 GB): The Linux VM that Claude desktop uses for code execution. Deleting just forces a re-download.

MacWhisper models (4.4 GB): Actively used speech models. If you only use one transcription backend, you could delete the other.

The Time Machine trap

After deleting ~90 GB of files, df -h showed basically no change in available space. Trash was already empty.

The culprit: Time Machine local snapshots.

macOS creates hourly snapshots of your disk as a safety net between backups. Normally they’re cheap (APFS copy-on-write). But when you delete a lot of files, the snapshots taken before those deletions still reference the old data. APFS can’t reclaim the blocks until the snapshots expire.

# See your snapshots
tmutil listlocalsnapshots /

# Delete them all (doesn't affect external backups)
tmutil deletelocalsnapshots /

After deleting the snapshots, available space jumped from 14 GB to 189 GB. If you’ve just done a big cleanup and the numbers don’t add up, this is probably why.

The scorecard

What	Freed
CoreSimulator logs	~49 GB
Dead simulator containers	~15 GB
iOS DeviceSupport (old version)	~5 GB
Ollama models	~12 GB
npm cache	~6 GB
Homebrew cache	~3 GB
Total	~90 GB

Why this works well with an AI

I’m not doing anything a human can’t do. It’s the same du command, run repeatedly, following the biggest number deeper.

But I don’t lose my train of thought 5 levels deep into a path. I check every simulator’s Dead folder in one pass. I can tell you whether containermanagerd/Dead is safe to nuke without you having to Google it. And when something shouldn’t be deleted (like DerivedData with a long rebuild), I say so instead of just nuking everything.

Storage cleanup is tedious, repetitive, and needs judgment at every step. That’s kinda the sweet spot.

Perhaps a hard skill.

I Vibe Coded a Mac App to Fix Xcode 26.4 Simulator Paste

Sat, 04 Apr 2026 17:08:00 +0800

Last week I shared the manual workaround for Xcode 26.4’s broken simulator paste. Running pbpaste | xcrun simctl pbcopy booted every time you want to paste gets old fast.

So I levelled it up with Claude and coded a Mac app.

The core

The one-liner that fixes it:

pbpaste | xcrun simctl pbcopy booted

Pipe the Mac clipboard into the Simulator’s pasteboard. Now poll for changes and run it automatically:

let pasteboard = NSPasteboard.general
var lastChangeCount = pasteboard.changeCount

while true {
    if pasteboard.changeCount != lastChangeCount {
        lastChangeCount = pasteboard.changeCount
        if let content = pasteboard.string(forType: .string) {
            let p = Process()
            p.executableURL = URL(fileURLWithPath: "/usr/bin/xcrun")
            p.arguments = ["simctl", "pbcopy", "booted"]
            let pipe = Pipe()
            p.standardInput = pipe
            pipe.fileHandleForWriting.write(Data(content.utf8))
            pipe.fileHandleForWriting.closeFile()
            try? p.run()
        }
    }
    Thread.sleep(forTimeInterval: 1.0)
}

That’s it. Run swift Sideboard.swift and copy-paste works again.

But polling? Really?

Yeah. Every clipboard manager does it.

macOS has no clipboard change notification. No NSNotification, no KVO, no callback. Hammerspoon’s source code says it plainly:

“macOS doesn’t offer any API for getting Pasteboard notifications, so this extension uses polling.”

Here’s what the popular ones do:

App	Stars	Method	Interval
Maccy	19.2k	`Timer` + `changeCount`	0.5s
Hammerspoon	15.1k	`NSTimer` + `changeCount`	0.25s

Our 1 second is plenty. You won’t notice the delay.

Sideboard App

That script became Sideboard, a macOS menu bar app. Bidirectional sync (Simulator to Mac) too, with clipboard history.

The core is still that same loop. Poll changeCount, pipe to simctl.

It’s a minimal app for now. But who knows how else it can be useful for 🤷🏻

Trust, but verify

A clipboard tool touches everything you copy. Passwords, tokens, private messages. So trust matters.

Sideboard is open source. You can read every line. But reading source doesn’t prove the DMG you downloaded was built from that source.

That’s why releases are built by GitHub Actions, not on my laptop. The CI pipeline builds from the tagged commit, signs with a Developer ID certificate, and notarizes with Apple. You can see the build logs for every release.

To verify your download:

shasum -a 256 ~/Downloads/Sideboard.dmg

Compare the output against the SHA-256 shown on the release page. If they match, you have the exact binary that CI produced from the source code you can read.

Faster & cheaper to build apps

With vibe coding, I went from a broken Xcode paste to a signed, notarized, open-source Mac app with a one-click release pipeline in a single sitting. The agent handled the parts I’d normally procrastinate on: the notarization dance, mac app scafolding, the GitHub Actions YAML.

Now I focused on what the app should do. Claude handled the implementation.

That’s the shift. The barrier to shipping isn’t writing code anymore. It’s all the stuff around the code. And that stuff just got a lot cheaper.

Xcode 26.4 Simulator Paste Is Broken: Here's the Workaround

Mon, 30 Mar 2026 12:00:00 +0800

After updating to Xcode 26.4, paste from Mac to iOS Simulator is completely broken. Cmd+V does nothing. Long-pressing a text field shows no “Paste” option. The Simulator’s clipboard is just empty.

Restarting the Simulator, toggling “Automatically Sync Pasteboard”, killall pboard, resetting privacy settings: none of it helps.

The workaround

Write directly to the Simulator’s pasteboard with simctl:

echo -n "your text here" | xcrun simctl pbcopy booted

This bypasses the broken Mac-to-Simulator auto-sync. Once run, paste works normally inside the Simulator. You still need another Cmd+V to paste into simulator.

Not great, but it works until Apple fixes it.

UPDATE: Even simpler

Herman Banken pointed out a simpler version, the same command every time, just like Cmd+C, Cmd+V:

pbpaste | xcrun simctl pbcopy booted

My AI Agent Watched 359 Episodes of Point-Free So I Don't Have To

Sat, 28 Mar 2026 18:00:00 +0800

Last post I set up Chrome DevTools MCP and showed how an AI agent can access anything in your logged-in browser. Reading newspapers, scraping custom viewers, reverse-engineering undocumented APIs.

Here’s what I actually used it for this week.

The subscription guilt

Point-Free is a Swift/iOS video series by Brandon Williams and Stephen Celis. They’ve been running since 2018. 359 episodes. 8 years of functional programming, architecture patterns, SwiftUI navigation, parsing, persistence, concurrency, and testing.

I’ve been a paying subscriber for a while. I’ve watched maybe 10 episodes. The content is genuinely excellent, but there’s no universe where I have 200+ hours to watch everything. So the subscription sits there, guilt-generating.

This week I pointed Claude Code at it.

What the agent did

The browser MCP gives Claude Code access to my logged-in session on pointfree.co. Most episodes are members-only, but since I’m logged in, the agent can navigate to any episode page and see everything I can see.

The workflow:

Navigate to an episode page
Run evaluate_script to find the transcript container in the DOM
Extract speaker names, timestamps, section headings, code blocks, and paragraphs
Save as a clean markdown file

For videos, the agent finds the Cloudflare Stream iframe, extracts the video ID, constructs the DASH manifest URL, and hands it to yt-dlp. But I didn’t need the videos. I wanted the text.

322 transcripts in one session

Instead of navigating to each page individually (which would take forever for 300 episodes), the agent used fetch() from within the browser context. Since the browser is authenticated, fetches to pointfree.co carry the session cookies. Each page’s HTML gets parsed with DOMParser in-browser, the transcript extracted, and the result stored in window.__transcripts.

20 episodes per batch. 15 batches. Each batch takes a few seconds to fetch and parse. Then the agent dumps the transcripts to disk via the tool results pipeline.

322 out of 359 episodes had transcripts. The 38 without were mostly early free episodes and livestreams that use a different page structure.

Parallel summarization

With all transcripts on disk, I asked Claude Code to summarize every episode. 5 agents ran in parallel, each handling 50-60 episodes. Each agent read every transcript file in its batch and produced a 5-sentence summary plus a list of frameworks used.

The result: a 2,578-line SUMMARY.md covering 322 episodes. Each entry looks like this:

## EP 327: Modern Persistence: Reminders Detail, Part 2

This episode pauses feature development to compare the StructuredQueries
approach against SwiftData. The hosts attempt to rebuild the reminders
detail query using SwiftData's @Model, @Relationship, #Predicate, and
SortDescriptor. They encounter numerous friction points...

**Frameworks:** SharingGRDB, StructuredQueries, GRDB, SwiftData, SwiftUI

Every episode. Searchable. Sortable by framework. Filterable by topic.

What fell out of the analysis

I asked the agent to analyze all 322 summaries and tell me what the series is actually about. The trends are striking.

2018-2019: Pure functional programming. map/zip/flatMap as universal abstractions, algebraic data types, protocol witnesses. No SwiftUI. No architecture. Just building vocabulary.

2019-2020: SwiftUI drops. They build the Composable Architecture from scratch over 35 episodes, deriving every design decision from the functional concepts taught earlier.

2020-2023: TCA evolves through 4 major iterations. Combine integration, async/await, ReducerProtocol, the Dependencies library. The isowords game and Standups app prove it works at scale.

2023-2024: Swift’s @Observable macro changes everything. They eliminate 6+ wrapper types from TCA’s API. The @Shared property wrapper solves cross-feature state sharing.

2024-2026: Hard pivot into persistence. Type-safe SQL query builders, a full Reminders clone with FTS5 search, SQLite triggers calling Swift functions, CloudKit sync. They’re now competing directly with SwiftData.

The agent identified 7 standout episode groups worth watching. The ones I found most interesting:

Protocol Witnesses (EP 33-39): The idea that protocols can be “de-protocolized” into structs with closure properties. This single insight shaped the design of SnapshotTesting, Dependencies, and TCA’s entire DI philosophy.
Parser-Printers (EP 178-189): A single value that parses input into typed data AND prints it back. The URL routing application where one router simultaneously handles server requests and generates client URLs is wild.
Reliable Async Tests (EP 238-242): They discover a hidden C-level hook (swift_task_enqueueGlobal_hook) in Apple’s concurrency runtime to make async tests deterministic. Systems-level work that nobody else had a clean answer for.

The deeper patterns

The agent also surfaced patterns I wouldn’t have noticed from watching individual episodes:

pullback appears in 6 different contexts across the series: functional setters, snapshot strategies, protocol witnesses, reducer composition, case paths, persistence keys. Same mathematical operation, different domains. Once you internalize it, you see it everywhere.

Apple keeps validating Point-Free’s bets. CasePaths predates Apple’s enum key path exploration. SwiftUINavigation predates NavigationStack. StructuredQueries/SQLiteData competes with SwiftData and wins on nearly every axis. They’re consistently 1-2 years ahead.

The real product is the library ecosystem, not TCA. Dependencies, Sharing, CasePaths, IdentifiedCollections, SwiftNavigation, CustomDump, SnapshotTesting, MacroTesting, StructuredQueries, SQLiteData. Each works independently without TCA.

These are the kind of insights you get from seeing all 359 episodes at once, which no human subscriber has time to do.

Why this matters

I now have a searchable knowledge base of a course I paid for but never had time to watch. When I’m working on a Swift project and need to understand how to model navigation with enums, the agent can reference the actual Point-Free transcripts and give me the approach they recommend, with the reasoning behind it.

The transcripts are sitting in my mac machine as markdown files. Any agent session can read them. The summaries and insights files give quick orientation. The full transcripts give depth when needed.

This is the real value of browser MCP. Not automating clicks. Not scraping data. Making content you’ve already paid for actually accessible to the tools you use every day.

Is this piracy?

I did not send any paid content to others. Unless my agents are considered “others”.

Any subscription content that renders in your browser is accessible to your agent. Video courses, news portals, research papers, e-newspapers. If you’re paying for it and the platform doesn’t offer a convenient export, the browser MCP is your export tool.

You’re not stealing from yourself.

You’re letting your agent access materials and learn for you.

How to Set Up Chrome DevTools MCP for Claude Code

Thu, 26 Mar 2026 12:00:00 +0800

I spent an afternoon getting Chrome DevTools MCP working with Claude Code. Made every wrong turn possible. Here’s the right way so you don’t repeat my mistakes.

Why you’d want this

This morning I asked Claude Code to read today’s Business Times for me. The e-paper sits behind an NLB login, rendered in a custom epub reader. No API. No RSS feed. No MCP for SPH’s newspaper platform.

Claude Code opened the tab, found the reader’s internal cciobjects.json endpoint, and pulled every article’s headline, byline, and full text in a single fetch. 35 articles across 8 sections. It picked the 5 most interesting stories and summarized them. Took seconds.

The naive approach (which I tried first) was screenshotting each page. 22 pages, one at a time, reading text from images. Slow, inaccurate, and I only got the top half of each page because I forgot to scroll. The smart approach: inspect the network requests, find the structured data, and fetch it directly. The agent figured this out on its own once I pointed out the screenshots were slow.

That’s the real power here. Not just “AI can click buttons in a browser.” It’s that your agent can access anything you can access, through your logged-in session, and it’s smart enough to find the fastest path to the data.

Paywalled content behind custom viewers. Newspapers, research papers, financial reports. If it renders in your browser, the data is there somewhere. The agent can inspect network traffic, find the underlying API, and extract structured text instead of OCR-ing screenshots.

Portals that will never have an API. Your landlord’s maintenance form. Government permit applications. That procurement system from 2009. One HN commenter nailed it: “This is to automate ticket submission to my landlord’s half-baked web portal.”

Reverse-engineering undocumented APIs. The agent navigates using your browser’s auth cookies, intercepts requests, and maps the real API surface. The e-paper example is exactly this: it found a clean JSON endpoint that the reader uses internally, then used it directly.

Verifying what your code actually renders. Your AI writes a CSS fix. Does it work? It reloads the page, inspects computed styles, takes a screenshot. No API tells you your flexbox container is inexplicably 5000px wide. Only the browser knows.

The pattern: browser access is irreplaceable when the content is behind auth, the interface is the only way in, or the rendered output IS the thing you care about.

Setup: the right way

3 steps. 2 minutes.

1. Install the full plugin

Don’t use claude mcp add. The full plugin gives you the MCP server plus 6 skills (a11y auditing, performance debugging, troubleshooting, etc).

claude plugin marketplace add ChromeDevTools/chrome-devtools-mcp
claude plugin install chrome-devtools-mcp

2. Enable `--autoConnect`

By default, the plugin launches its own Chrome. You don’t want that. You want your real browser with all your tabs and logins.

Edit the plugin config:

vim ~/.claude/plugins/cache/claude-plugins-official/chrome-devtools-mcp/latest/.claude-plugin/plugin.json

Add --autoConnect:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--autoConnect"]
    }
  }
}

Requires Chrome 144+. You’re probably already there.

3. Enable remote debugging in Chrome

Navigate to chrome://inspect/#remote-debugging and check “Enable remote debugging”.

Chrome asks you to confirm. Click Allow.

Restart Claude Code. Verify with list_pages, it should show all your open tabs.

One caveat: the --autoConnect edit lives in the plugin cache. Plugin updates might overwrite it. One-line fix if that happens, but not ideal.

How it works

The MCP uses Chrome DevTools Protocol to talk to your browser. With --autoConnect, it finds your running Chrome directly. No special launch flags.

Claude Code gets a set of tools: list_pages, select_page, navigate_page, take_snapshot, take_screenshot, click, fill, evaluate_script. It switches tabs, reads page content via the accessibility tree, captures network requests, runs JavaScript.

The workflow: navigate, wait, snapshot (text-based, faster than screenshots), interact using element IDs.

The scenic route (what not to do)

Here’s what I actually did before figuring this out.

Mistake 1: MCP-only install

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

This skips the skills. The troubleshooting skill alone would’ve saved me an hour. Use the full plugin.

Mistake 2: The `--remote-debugging-port` rabbit hole

Without --autoConnect, the MCP launches its own Chrome. I saw a single about:blank tab and panicked. Down the rabbit hole of launching Chrome from terminal:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

Chrome won’t enable this on your default profile:

DevTools remote debugging requires a non-default data directory.

So you need --user-data-dir pointing somewhere else. Fresh profile, no logins, no cookies. Terrible.

Mistake 3: Copying the entire Chrome profile

I actually ran this:

cp -r ~/Library/Application\ Support/Google/Chrome ~/Library/Application\ Support/Google/Chrome-Debug

It worked. Technically. But it’s a snapshot that drifts from your real profile immediately. And you have to launch Chrome from terminal every time with the right flags.

The whole thing felt off. Because --autoConnect exists and none of this was necessary.

Mistake 4: Not reading the docs

The biggest one. npx chrome-devtools-mcp@latest --help would’ve shown me --autoConnect immediately. The plugin’s troubleshooting skill existed for exactly this situaton.

Read the docs first. Always.

(I say this knowing I won’t follow my own advice next time.)

Or use the right skills.

What Your AI Code Reviewer Actually (Prompts) Behind Your Back

Wed, 25 Mar 2026 10:00:00 +0800

I run /review before every PR push. It’s part of the workflow now.

But I never looked at what’s behind it. What instructions is the model actually following? What’s it told to flag, ignore, prioritize? I just trusted it works.

So I pulled the full prompts from both Claude Code and Codex CLI. The difference is bigger than I expected.

Claude Code’s hand

Claude Code’s /review is transparent. The prompt gets injected into the conversation when you invoke it. You can find it in Piebald-AI/claude-code-system-prompts, which tracks every release.

Here’s the entire thing:

You are an expert code reviewer. Follow these steps:

1. If no PR number is provided in the args, run `gh pr list` to show open PRs
2. If a PR number is provided, run `gh pr view <number>` to get PR details
3. Run `gh pr diff <number>` to get the diff
4. Analyze the changes and provide a thorough code review that includes:
   - Overview of what the PR does
   - Analysis of code quality and style
   - Specific suggestions for improvements
   - Any potential issues or risks

Keep your review concise but thorough. Focus on:
- Code correctness
- Following project conventions
- Performance implications
- Test coverage
- Security considerations

Format your review with clear sections and bullet points.

That’s it. ~200 tokens. No bug criteria. No priority system. No output format. No guidance on what not to flag.

“Read the diff and tell me what you think.”

Codex’s hand

Codex is open source too. The review prompt lives in codex-rs/core/review_prompt.md, compiled into the Rust binary via include_str!.

Considerably more opinionated:

You are acting as a reviewer for a proposed code change
made by another engineer.

Your job is to find bugs introduced by the patch.
Do not give a general PR summary unless it helps explain
the findings. Do not optimize for volume.
If there are no issues the author would definitely want
to fix, say so plainly.

Then 6 gating criteria. An issue only gets flagged if all are true:

Meaningfully affects correctness, reliability, performance, security, or maintainability
Discrete and actionable
Introduced by this change, not pre-existing
Doesn’t depend on unstated assumptions
You can point to exact code and explain the concrete failure mode
The author would likely fix it if told

And an explicit “do not flag” list: style nits (unless they obscure meaning), speculative risks without a concrete path, broad architectural opinions, intentional behavior changes.

Priority levels P0 through P3. A strict output template. And behavioral guardrails: “Prefer no finding over a weak finding. Do not praise the author. Do not pad the review with generic comments.”

The gap

	Claude `/review`	Codex `/review`
Prompt length	~200 tokens	~600 tokens
Bug criteria	None	6 explicit gates
“Do not flag” rules	None	4 exclusions
Priority levels	None	P0 through P3
Output format	“Sections and bullet points”	Strict template with verdict
Pre-existing bugs	Not addressed	Explicitly excluded
False positive control	None	“Prefer no finding over a weak finding”

Claude trusts the model to figure out what a good review looks like. Codex tells the model exactly what counts and what doesn’t.

In practice

I’ve been running both on real PRs. Codex consistently flags better findings.

The priority system is the killer feature. P0 and P1 genuinely need fixing. P2 and P3? Mostly not worth the churn. That triage is built into the output. Scan, fix what matters, move on.

Claude’s /review gives you a wall of bullet points at the same level. You do the triage yourself. Which kinda defeats the point.

One caveat: if you search for “Claude Code Review benchmark,” you’ll find articles claiming less than 1% false positive rates. That’s not the built-in /review. That’s a separate /code-review plugin with a completely different architecture.

Claude’s other reviewer (the one nobody uses)

Claude Code ships an official /code-review plugin that’s far more sophisticated than /review. It’s an 8-step pipeline:

Eligibility check (skip drafts, closed PRs, automated PRs)
Gather CLAUDE.md files from affected directories
Summarize the PR
Launch 5 parallel Sonnet agents, each reviewing from a different angle: CLAUDE.md compliance, obvious bugs, git blame history, previous PR comments, and code comment compliance
Score every finding 0-100 with Haiku agents using a detailed rubric
Filter to 80+. If nothing qualifies, it stops and posts nothing.
Re-check PR is still open
Post a gh pr comment with only the surviving findings

If nothing scores 80+, it posts nothing. That’s the reviewer the benchmarks are testing. Not /review.

	`/review` (built-in)	`/code-review` (plugin)	Codex `/review`
Architecture	Single pass	8-step, 9-15 model calls	Single pass
Prompt size	~200 tokens	~1500 tokens + 5 agent prompts	~600 tokens
Bug criteria	None	Implicit via 5 specialized angles	6 explicit gates
False positive control	None	10 examples + 0-100 scoring, 80+ threshold	6 “do not flag” rules
Priority system	None	Confidence score	P0-P3
Output format	“Sections and bullet points”	Strict template with GitHub permalinks	Strict verdict template
Posts to GitHub	No	Yes (only if 80+ findings)	No
No findings	Generic review anyway	Posts nothing	“patch is correct” + residual risks
Cost per review	1 call	9-15+ calls	1 call

The plugin is powerful but expensive. Codex achieves surprisingly close quality in a single call through better prompt engineering. Claude’s plugin throws compute at the problem.

The trade-off nobody talks about

Codex compiles its review prompt into the Rust binary. You can’t change it without rebuilding from source. There’s a review_model config to swap the model, but the instructions are locked.

Claude’s prompt is a replaceable markdown file. You could paste Codex’s entire prompt into .claude/commands/review.md and get Codex-quality instructions running on Claude’s model. Or write something better tuned for your stack.

Codex chose polish. Claude chose extensibility.

I’m not sure which is right. But I know which one I can fix myself.

The real lesson

~400 tokens of difference separates “generic feedback” from “structured, prioritized, low-noise findings.” The models are the same tier of capability. The instructions make the difference.

This applies to every AI tool you use, not just code review. There’s always a prompt behind it. The quality of that prompt determines whether you get useful output or plausible-sounding noise.

Now you’ve seen what yours actually says.

Maybe it’s time to customize your review instructions.

AI Agents Write the Code Now. So What's a Developer For?

Tue, 24 Mar 2026 16:00:00 +0800

Our team has mostly moved to agent-driven development. Agents create tickets, write the code, open PRs, and post review comments. The output is way up. More PRs, more lines, more velocity.

But there’s also more bugs. A lot of recent PRs are just fixing regressions from other agent-generated PRs. Or reverting changes that broke something adjacent.

I don’t think we’re unique here. Any team using agents heavily is probably hitting this.

The review burden

Here’s the part I didn’t expect: reviewing PRs as a human is more tiring now, not less.

Net productivity has increased. But the lines of code per feature has increased too, as well as PR comments (agents tend to be very verbose). So much more to read that real human review can no longer catch up.

The diffs are bigger. The context is harder to trace. I have to check whether the PR accidentally undoes something someone else shipped last week. To review properly, I need to understand the problem, check the history, trace the affected systems, verify the approach doesn’t break adjacent behavior.

At that point I’ve basically done the same work as if I’d taken the task myself. Except I didn’t choose the approach, so now I’m reverse-engineering someone else’s (or some agent’s) decisions.

And if I use an agent to review? Agent reviews flag a mix of real issues, edge cases that’ll never happen, and outright non-issues. When the developer tells the agent “address all review comments” without triaging, the follow-up commits sometimes introduce regressions from changes that didn’t need to happen.

The code gets messier with each round.

A shift in code review

For the last 20 years, PR review was where senior developers mentored juniors. You’d point out conventions, share domain knowledge, explain why a certain approach is better. The junior reads your comments, learns, writes better code next time.

It occurs to me that my PR comments are no longer being read by humans. An agent reads them, applies the fixes, moves on. The developer probably never sees them.

If I point out a better convention or a cleaner pattern, there’s really no point. The agent won’t remember it next time. And honestly, the agent knows the better approach.

So if my review comments are just a conversation with an agent that forgets everything by the next PR, what’s the point?

I think the point changes.

You’re not mentoring anymore.

Focus on architecture and boundaries

What’s still worth reviewing is the shape of the solution. Not the code itself.

Does this logic belong on the client or the server? Should this live in the API layer or the domain layer? Is this feature creeping into a service that shouldn’t own it? Should this be a separate module, a separate boundary entirely?

These are architectural questions. Agents don’t think about them. They solve the ticket in front of them, in the file in front of them. They won’t suggest “actually, this problem is better solved two layers up” or “this should be a server-side concern, not client-side.” They don’t reason about where responsibilities should live across a system.

So that’s what review becomes. You’re reviewing the solution, not the code. Not the style, not the comments, not the naming. Leave that to linters. There’s too much code now anyway, and honestly, agents read code better than we do.

The value of a human reviewer is pointing out: “This works, but it’s in the wrong place.”

Responsibility hasn’t changed

One thing that hasn’t shifted: whoever works on the task owns it.

The reviewer’s job is to point out how things could be done better. That’s it. The reviewer doesn’t take on responsibility for the outcome.

The developer who opens the PR is responsible. They have to test it. In fact, testing matters more now than before, because the developer didn’t write the code. An agent did. You can’t rely on the intuition of “I wrote this, I know it works.” You have to actually verify.

The developer has to own that baseline: does this work, does it break anything adjacent, is it actually correct. And when something breaks in production later, the developer picks it up and fixes it. Not the reviewer. Not the agent.

More agent code means more code. More code means more bugs. That’s an invariant that never changes.

tmux cheatsheet

Mon, 23 Mar 2026 09:45:00 +0800

tmux has become more useful whenever I need to SSH from my mobile device to my main running computer. Here are some frequently used commands.

Create a new session

Provide your session name, eg. “mayday”

tmux new -s mayday

With that you can list list all the sessions

tmux ls

Attach to the session

tmux attach -t mayday

Bonus: To be the single controller and detaching all others, add a -d flag.

Create/Attach

Probably the best way is to create if needed, else attach

tmux new -As mayday

Detach from the session

Since you’re already in the tmux session, you don’t issue a command, but press Ctrl+b then d (detach).

Terminate a session

While detach still keeps the session alive, to really teminate it you have to kill it.

tmux kill-session -t mayday

Pane Management

Ctrl+b first, then

Split pane with % (vertically) or " (horizontally)
Jump to next pane o, zoom pane z, kill pane x
Enter copy/scroll mode [

Send keys

Send key strokes directly to a session, great for automation:

tmux send-keys -t mayday 'npm run dev' C-m

The C-m is sending Enter.