Cmd+clicking links in the terminal would occasionally crash the app:
EXC_BAD_ACCESS / SIGSEGV
KERN_INVALID_ADDRESS at 0x0000000000000010
The crash happened in _platform_memmove called from process.Child.spawn. Classic memory corruption - the stack trace points at libc internals and tells you nothing useful.
Here’s the problematic code (simplified):
fn openUrl(allocator: std.mem.Allocator, url: []const u8) !void {
const thread_allocator = std.heap.c_allocator;
const owned_url = try thread_allocator.dupe(u8, url);
const child = std.process.Child.init(
&.{ "open", owned_url }, // <- stack-allocated argv
allocator
);
const thread = try std.Thread.spawn(.{}, openUrlThread, .{ thread_allocator, child, owned_url });
thread.detach();
}
fn openUrlThread(thread_allocator: std.mem.Allocator, child: std.process.Child, owned_url: []u8) void {
var process = child;
_ = process.spawnAndWait() catch {};
thread_allocator.free(owned_url);
}
&.{ "open", owned_url } creates a temporary array on the stack. Child.init stores a pointer to this array. When child is passed to the thread, the struct is copied, but it still holds a pointer to the original stack memory. The function returns, reclaiming the stack frame. Thread tries to spawn using the now-invalid argv pointer. Crash.
Put the argv array in a heap-allocated context struct:
const ThreadContext = struct {
allocator: std.mem.Allocator,
url: []const u8,
argv: [2][]const u8,
fn deinit(self: *ThreadContext) void {
self.allocator.free(self.url);
self.allocator.destroy(self);
}
};
fn openUrl(_: std.mem.Allocator, url: []const u8) !void {
const thread_allocator = std.heap.c_allocator;
const ctx = try thread_allocator.create(ThreadContext);
errdefer thread_allocator.destroy(ctx);
ctx.allocator = thread_allocator;
ctx.url = try thread_allocator.dupe(u8, url);
errdefer thread_allocator.free(ctx.url);
ctx.argv = .{ "open", ctx.url };
const thread = try std.Thread.spawn(.{}, openUrlThread, .{ctx});
thread.detach();
}
fn openUrlThread(ctx: *ThreadContext) void {
defer ctx.deinit();
var child = std.process.Child.init(&ctx.argv, ctx.allocator);
_ = child.spawnAndWait() catch {};
}
The context lives on the heap and owns everything the thread needs. The Child is created inside the thread function, so its argv pointer points to heap memory that remains valid.
Finding this bug manually was annoying. Intermittent crash, stack trace pointing nowhere useful, actual cause buried under several layers of indirection.
I wanted zwanzig to catch this. The pattern: a pointer to something on the stack gets passed to a detached thread, and the function returns before the thread finishes.
I wrote a checker called stack-escape-engine:
Thread.spawn + detachIt catches the exact pattern from the bug:
// zwanzig catches this:
const child = std.process.Child.init(&.{ "open", owned_url }, allocator);
const thread = try std.Thread.spawn(.{}, openUrlThread, .{ allocator, child, owned_url });
thread.detach(); // <- "Stack-backed value escapes via thread"
It also handles argv constructed via switch (the actual cross-platform code uses one), helpers wrapping the spawn call, etc. The test suite covers the patterns I could think of.
Every time I fix something subtle, I ask: could a tool have caught this? Sometimes no - the bug needs runtime context or is too dynamic. But stack escapes via thread captures? That’s a pattern. Patterns can be detected.
If you’re writing Zig:
git clone https://github.com/forketyfork/zwanzig
cd zwanzig && zig build
./zig-out/bin/zwanzig /path/to/your/project
The stack-escape-engine checker is on by default in v0.6.0+.
Links:
The problems I’ve faced:
Here’s what happens when you run 4 Claude Code sessions in multiple terminal tabs: nothing, visually. All four tabs look the same. One agent finishes and sits there, waiting for your next prompt. Another hits a permission check and needs approval. You don’t notice because you’re focused on tab 3, watching it churn through a file. Twenty minutes later you realize agent 1 has been idle the whole time.
I tried the obvious solutions — desktop notifications, but they come and go at the operating system’s whim. Multiple terminal windows arranged carefully. A second monitor dedicated to “the agents.” None of it worked because the fundamental problem remained: terminals don’t know what’s running inside them.
A shell prompt looks the same whether the last command succeeded, failed, or is waiting for human input. There’s no semantic information.
Architect is a terminal I wrote specifically for this workflow. Show all sessions in a grid, make it easy to switch between them, make it visually obvious which ones need attention.
When an agent finishes a task, the cell hue changes. When it’s waiting for approval, it glows. At a glance, I know where to focus.
That’s it. That’s the feature.
Everything else — the smooth animations, the expand/collapse, the keyboard shortcuts — exists to make this core loop fast. See the grid. Spot the agent that needs you. Expand. Respond. Collapse. Back to the grid.
I start with a single terminal. When I need another, I hit ⌘N and the grid expands automatically. When I’m done with one, ⌘W closes it and the grid contracts. If I need to focus on a specific terminal, I hit ⌘Enter, or do a long Esc hold to pop back to the grid.
If I need multiple tasks in the same repo, I hit ⌘T to open a worktree popup. ⌘0 creates a new worktree, ⌘1/⌘2/⌘3… switches to an existing one. I can delete worktrees from the same popup. The integration works by sending git commands to the terminal — fully traceable, no magic.
It’s based on hooks. Many agents support them, so it’s not limited to the big 3. I provide a Python script you can call to highlight the cell where it’s running.
I learned a lot of agent quirks along the way:
Stop), then triggers another hook (Notification) after ~10 seconds if you don’t react. So the cell turns green, then yellow.AfterAgent notification after every step instead of just once at the end — known issue.I wanted to learn Zig, and terminal emulators are a good project for it. Also, Architect builds on ghostty-vt, which is written in Zig — using the same language meant I could integrate directly without FFI overhead. SDL3 for rendering, ghostty-vt for terminal emulation, Zig for glue.
Architect is early. I use it daily, but there are gaps:
Agent detection is also limited to a handful of tools.
If you’re running multiple AI agents and fighting the same attention problem, give Architect a shot.
Download the latest release or install via Homebrew:
brew tap forketyfork/architect https://github.com/forketyfork/architect
brew install architect
cp -r $(brew --prefix)/Cellar/architect/*/Architect.app /Applications/
Issues and PRs welcome.
I’ve been building a few other tools for multi-agent workflows:
ps aux, scroll through output, find the target, copy the PID, then kill it. Or maybe grep for a pattern, parse column 2, and hope I picked the right one.
Now I use a better way. Meet fzkill: a shell function that I use to interactively fuzzy-search my running processes and kill them with immediate visual feedback.
fzkill() {
local pid=$(ps aux | fzf --header="Select a process to kill" --preview="echo {}" | awk '{print $2}')
if [ -z "$pid" ]; then
print -P "%F{yellow}❌ No process selected, operation canceled%f"
return 1
fi
if kill "$pid" 2>/dev/null; then
print -P "%F{green}✅ Successfully killed process $pid%f"
else
print -P "%F{red}⚠️ Failed to kill process $pid (may require sudo or process doesn't exist)%f"
return 1
fi
}
Run fzkill, start typing to filter processes, hit Enter, done. I get:
You need fzf installed. Most package managers have it, I use brew:
# macOS
brew install fzf
Add the function to your ~/.zshrc:
fzkill() {
local pid=$(ps aux | fzf --header="Select a process to kill" --preview="echo {}" | awk '{print $2}')
if [ -z "$pid" ]; then
print -P "%F{yellow}⚠️ No process selected, operation canceled%f"
return 1
fi
if kill "$pid" 2>/dev/null; then
print -P "%F{green}✅ Successfully killed process $pid%f"
else
print -P "%F{red}❌ Failed to kill process $pid (may require sudo or process doesn't exist)%f"
return 1
fi
}
Reload your shell:
source ~/.zshrc
Add to your ~/.bashrc:
fzkill() {
local pid=$(ps aux | fzf --header="Select a process to kill" --preview="echo {}" | awk '{print $2}')
if [ -z "$pid" ]; then
echo -e "\033[0;33m⚠️ No process selected, operation canceled\033[0m"
return 1
fi
if kill "$pid" 2>/dev/null; then
echo -e "\033[0;32m✅ Successfully killed process $pid\033[0m"
else
echo -e "\033[0;31m❌ Failed to kill process $pid (may require sudo or process doesn't exist)\033[0m"
return 1
fi
}
Reload:
source ~/.bashrc
Why kill instead of kill -9?
SIGTERM (the default) lets processes clean up gracefully: flush buffers, close connections, save state. SIGKILL (-9) is immediate and brutal, leaving the proces no time to cleanup.
Why fzf? Interactive fuzzy search is better than grepping. You see what you’re about to kill, and you can type partial matches: “chro” finds Chrome, “node” finds all Node processes.
fzkill. “python”, “node”, “postgres” - fzf narrows as you type.ps aux line, so you can double-check before killing.sudo. Or the process died between selection and kill.kill "$pid" to kill -9 "$pid".xargs and adapt the selection logic.| grep $USER before fzf.
What Ollama Gets Right:
Where Ollama Falls Short (for now):
For now, I’ll probably keep both. Enchanted LLM still has features I rely on daily, but it’s been stagnant — no updates in over a year. Ollama feels more modern and active, so I’m keeping an eye on how fast it evolves.
]]>I care about both. So, to stay mindful of my Claude Code spend, I built a small macOS app that puts the current usage right in the menu bar:
It’s called Claude Nein — a pun on “cloud nine.”
Since I’m not eager to hand Apple $99/year just to ship an open-source menu bar app, it’s published unsigned. That means you’ll need to jump through some Gatekeeper hoops to run it. Still, it builds cleanly from source, and I’d love feedback, bug reports, or contributions.
]]>When I start a request with “please,” I force myself to slow down and think — I’m careful with words, I clarify what I really want. If I just bark commands, I stay in hurry, sloppy mode. That tiny ritual—taking a breath, choosing words—already cools my mood.
And when the task is done, I type “thank you.” Again, it’s not for the AI’s sake—it doesn’t feel gratitude—but for mine. It closes the loop — I feel I’ve completed a little exchange properly. Without it, everything is just open orders and unfinished business buzzing in my head. With it, I can move on.
Sure, some day AI will pretend to care. Today, it doesn’t matter. The real benefit is in me staying sane, staying human. If politeness can shift my mindset by a degree — make me calmer, more focused, more thoughtful — then it’s worth sounding old-fashioned. Try it. Say “please” and “thank you” to your next AI — don’t do it for the bot, do it for you.
]]>Now imagine booking a ticket was actually fast and pleasant. Imagine the person building that system cared about making it fast and pleasant. But no. “Make this seamless and effortless” — said no product manager ever. Instead, it’s all about “engagement,” making sure users spend more time on our bloated, ad-infested site. You log in, get subscribed to newsletters you never asked for, and get pushed through a dark pattern funnel just to give someone your money.
Booking a concert ticket shouldn’t take three hours. But it does. Why? Because of:
Of course people want an AI to deal with this mess. But let’s be honest — the real problem is we’ve normalized awful UI everywhere. And instead of fixing it, we’re now duct-taping bots over the top.
Picture this: a single global platform for booking concert tickets (flights, rides, etc.) The UI? One clean form:
No 15 tabs open. No forced account creation (seriously, give me one good reason I need to “register” to buy something — I’ll wait). No spam. No verification circus.
If you build it right, there’s no need for AI. Just good UX.
Sure, having one interface for everything sounds dystopian. But maybe it’s just… rational? We crave tools that are predictable, fast, and usable. Instead, we get a dozen half-baked services and then bring in AI as a bandaid.
Until we actually build good interfaces, we’ll keep wasting time developing AI that papers over our own failures. So let’s stop asking how AI can make things easier — and start asking why things are so hard in the first place.
]]>