Leveling Up Claude Code with Boris Cherny's Help
Cherny's thread on how he personally uses Claude Code gave me a roadmap.
I think about the kit of electronic tools that support my work as “The Workflow” and man, did I have a lot of ideas for new tools, improvements, and fixes. This 2XL-sized backlog lived in my head until June ‘25, when I started a “Workflow Tool ToDos” list in Obsidian. I made progress here and there, with my Obsidian implementation as one example. But movement was more sloth than cheetah.
Claude Opus 4.5 arrived in November, powering up Claude across all its surfaces—Claude.ai, Claude Desktop, and Claude Code. So smart, such encyclopedic knowledge. I used Opus, of course, when I ran into setup issues on tools like Cursor and Obsidian. But then it occurred to me: what if I made The Workflow itself a project, with a number of specific subprojects, and got very intentional about applying AI to level up? This turned into a rich vein of gold that I’ve been mining ever since, and actually led to my largest AI side projects to date, including Skillport. AI granted me the power to radically and continuously improve The Workflow, something I never would have been able to tackle on my own—without my AI pair, there’s just too much hard-to-find knowledge needed, too much work involved for each improvement.
But let me focus here on Claude Code.
Sucking Wind on Claude Code … Where to Start?
One of my deepest Workflow desires was to tune up my Claude Code setup, to use it the way I knew it could be used. The problem was, pretty much every aspect of my setup was subpar. Where the heck do I start?
Boris Cherny, the creator of Claude Code, came to my rescue. He posted a great 15-tweet thread about how he personally uses Claude Code. Unlike the rest of us, though, Cherny is using Claude Code to actually write Claude Code. You can see the thread here on Twitter, or here on Threadreader.
The Thread, Tweet by Tweet
| Reactions | ToDos |
|---|---|
| ”Vanilla” setup–right! | |
| Hmmm, this isn’t that crazy to try to replicate | Replicate Boris’s setup |
| 99K bookmarks, is that a record? |
| Reactions | ToDos |
|---|---|
| 5 terminal windows. That’s clean. | Get serious about my terminal setup |
| Wait, where’s the IDE? No IDE?! | Get off Cursor, assess whether I keep an IDE at all |
| Notifications from hidden terminals, nice! | Configure terminal notifications |
| Reactions | ToDos |
|---|---|
| Oh man, gotta get over the hump on Claude Code web | Get Claude Code web up and running including verifiable testing |
| Teleport back and forth! | Experiment with teleport |
| Claude Code in iOS app … what ?? | Try CC sessions from iOS app |
| Reactions |
|---|
| Opus 4.5. Already a convert but Boris makes a great case |
| Reactions | ToDos |
|---|---|
| Nice CLAUDE.md tips | Keep updating on every deviation |
| Reactions | ToDos |
|---|---|
| Interesting use of Claude GitHub app/action to update CLAUDE.md | Get Claude GitHub action working in a multi-account setup |
| Reactions | ToDos |
|---|---|
| Ahhh … I usually force Claude to save plans under /docs but this is suboptimal for Claude and me both | |
| I can trust Plan Mode on tasks unlikely to span multiple coding sessions | Try this! |
| Reactions | ToDos |
|---|---|
| I’m partway there … | Create /commands for the common inner-loop workflows I haven’t covered yet |
| Reactions | ToDos |
|---|---|
| I’m running some subagents via official Claude Skills, but haven’t done my own–untapped potential | Start building my own custom subagents |
| Reactions | ToDos |
|---|---|
| Hooks: more untapped potential. | Start leveraging hooks |
| Format hook PostToolUse, smart idea | Get this in place |
| Reactions | ToDos |
|---|---|
| Permission prompts are my #1 pain point with Claude Code | Need to sort this |
| Claude Code has a known bug where using global + project permissions together fails, globals get ignored | See if that’s still the case and what the workarounds are |
| Reactions | ToDos |
|---|---|
| Now that Claude Code has Tool Search, I can use more MCPs … | Configure more MCP servers |
| Shared config checked into repo via .mcp.json, cool | Look into this |
| Reactions | ToDos |
|---|---|
| Verifying work using a background agent, and Stop hook: very interesting … | Find a use case to try |
| Ralph Wiggum plug-in! OMG. | Ditto. |
| Reactions | ToDos |
|---|---|
| Give Claude a way to verify its work. 2-3x quality improvement. YES. | Dive in on getting to “verifiable code” with current projects. Start using it on foreground CC sessions as well as Claude Code web background and long-running Wiggum-type sessions |
| Browser testing | Get effective browser testing harness in place including authentication |
| Reactions |
|---|
| Thanks, Boris, for keeping this relatively simple and approachable. You encouraged me, rather than scaring me off. |
What I’ve Actually Changed So Far
I figured, what the hell, dive right in, starting with “ditching the IDE.”
I Ditched Cursor (VSCode) but Kept a Lightweight IDE (Zed)
Back when I used VSCode itself, the experience was janky and configuration a nightmare. I’ve been using Cursor since it arrived, and as a VSCode fork, it inherits those same drawbacks. Furthermore, once Claude Code launched, my use of AI in Cursor dropped off dramatically.
I shifted to using the Claude Code VSCode plugin in Cursor, which enabled easier multiline editing than CC-in-terminal. Over time, though, I hit more and more cases where the VSCode extension couldn’t do things that CC-in-terminal could. Friction.
As I got up to speed on Claude Skills and phased out Cursor Rules, I realized I was using Cursor as nothing more than an IDE, and in fact, the AI stuff in Cursor was just getting in the way. So I’m effectively paying $20/mo for the privilege of using VSCode with added AI annoyances (though I hear AI Annoyance has arrived in VSCode, too, in recent releases).
I chose not to ditch the IDE altogether, like Cherny apparently did. I still look at code regularly, and as I am now, I write in my IDE. No AI slop posts on cto4.ai. Instead, I went light-and-clean with Zed, which has been such a breath of fresh air after living in Electron apps for several years. So much is built-in and fast—I’ve installed a total of three extensions in Zed; I just checked and I had 48 installed in Cursor (!!). With just three extensions, Zed gives me a comparable feature set in a lighter, snappier, more coherent package.
Zed gets a smaller slice of my widescreen; the CLI gets significantly more:
I Supercharged my CLI: CLI-Mesh
Before the Cherny post, my terminal setup had barely progressed beyond basic macOS terminal, mainly experiments with Kitty and Ghostty. But I spent almost all my time in the IDE, using Claude mostly through its VSCode extension.
I split my time between two Macs, a deskbound M4 Mac Mini, and a mobile M1 Max MacBook Pro. Because I mostly wasn’t operating in CLI mode, I hadn’t set things up for easy SSH between machines.
Cherny’s setup appears to be Ghostty with splits; but many CLI advocates recommended using a good terminal app augmented by tmux, which adds terminal session-group-persistence—reattach and all your terminal windows are just as you left them. And tmux works nicely across machines, which was my use case.
I’d never used tmux and it took a while to get my head around it. I also learned through painful experience that you must avoid the dreaded Cross Machine Infinite Terminal Mirror where machine A tmux-attaches to machine B, which has a window attached back to machine A, and bam—lockup. In one case, Wezterm consumed 250GB of application memory on my Mac Mini, which went unstable and needed a reboot.
In the end, I landed on iTerm2 which has significant support for tmux, configured to avoid infinite mirror. With Claude Code’s help, I also did some ssh and .zshrc tuning to make cross-machine access super low friction. The result is what I term “CLI-Mesh” between the two Macs, where I can access persistent CLI sessions on the Mini from the Macbook and vice versa. “Anything from anywhere” thanks to CLI-Mesh is pretty sweet.
Sorting Permissions in Claude Code
I was convinced that Claude Code had a known, unresolved bug where using global + project permissions together would fail, with globals getting replaced by project permissions rather than the two being merged. Based on this, Claude and I implemented a permission scheme based solely on a PreToolUse hook rather than global permissions settings. This worked, but I kept wondering, would the Claude Code team allow a serious bug like this to persist for months? I kept asking CC to recheck the open ticket, and kept getting the answer, “still unresolved.”
Today I dug deeper and noticed someone had apparently discovered the supposed bug was actually caused by incorrect paths when specifying permissions for file operations—using / instead of // for absolute file paths. Once the paths were fixed, global permissions on file operations worked fine. It has been rumored that, at some point, Claude Code may have been incorrectly writing file paths when users approved file permissions, but I wasn’t able to confirm that in researching or testing today.
Anyway! Today I went back and moved everything that could be moved from the PreToolHook to Claude’s Global Permissions settings. There were a few things that needed to stay in the hook: piped/compound commands, as well as restrictive git and gh subcommand parsing. The hook can handle these more complex rules because it receives the full command and runs code to parse it, splitting on pipes, extracting subcommands, checking against allowlists. Native permissions only do simple pattern matching on the raw command string.
The good news is that I didn’t have to actually do the work, Claude Code did—including writing Python hook scripts to parse commands. The better news is that Claude Code operation is so much more streamlined, without needing to --dangerously-skip-permissions. (I will try living dangerously, safely, once I get more into Claude Code web and long running tasks.)
Using Skills and Other Plugins in Claude Code
When Cherny’s post landed, I was in the process of an extreme deep-dive into Skills and all the other varieties of Plugins: /commands, agents, hooks, MCP servers, and Language Server Protocol (LSP) servers. This was due to my Christmas break project, Skillport, which brings repository-based Skill distribution to all Claude surfaces including Claude Desktop and Claude.ai, and allows organizations to host their own private Skill repos. Because I wanted Skillport’s git-based repositories to be 100% compatible with Anthropic’s Plugin Marketplace format, I needed to know exactly how that format worked and what it supported.
Although I was already pretty far along with using Skills in Claude Code, Cherny’s post lit a fire under me to start using all the other plugin varieties. I’ve got one sophisticated use of hooks in place now, and am experiencing agents thanks to the PR Review plugin. I’m looking for an opportunity for custom agents next.
Much remains to be done, but thanks, Boris Cherny, for the inspiration.
