Apologies to those who received an email with broken images! Resending to correct that. And welcome to new subscribers!

My day job these days is helping organizations with all things technology as a fractional CTO. My side job? Continuous immersion in the latest AI, constantly pushing the boundaries of what is, and is not possible with today’s models and tools.

May you prosper in The Emergence!

Anthropic added plugin support: Cowork now runs on the same plugin system as Claude Code. And, they shipped 11 knowledge work plugins covering finance, legal, marketing, sales, product management, and more. Details here.

This is a longer post, you may want to read it here.

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.

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.

I figured, what the hell, dive right in, starting with “ditching the IDE.”

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:

Note that I use the AeroSpace tiling window manager, so rather than 5 splits in a Ghostty window, I have 35 wide screen workspaces to work with, each laid out like the above.

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.

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.)

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.