What jumps out to me isn’t the AppleScript, or even the somewhat Rube Goldberg plan of watching Terminal tabs for a Claude Code dialog and then poking Enter for them. It’s that the author is describing a problem space where the obvious “just automate it” answer keeps colliding with macOS security in different ways, and one of those collisions is silent. Silent failures are the worst kind, especially when you’re debugging background automation that is supposed to babysit an unattended machine.
I buy the basic shape of the story: if Claude Code’s Computer Use approval really only lives in session memory, then there may not be a clean settings-based escape hatch. That part sounds plausible, and the strings spelunking is at least the sort of dirty evidence I’d expect from someone trying to prove a negative. But I’m less comfortable with the implied confidence around the broader workaround. “Launch it as a child of Terminal” may work for this setup, but that smells like a brittle truce with the platform, not a principle. I’d want to know how often that breaks across Terminal updates, macOS releases, or a change in how Claude Code surfaces the dialog.
The more interesting bit is the safety work in the watcher itself. The author doesn’t just blast Enter whenever a string appears; they try to confirm the cursor is on “Allow for this session” first. That’s the right paranoia. If you’re going to automate approval dialogs, the failure mode isn’t “nothing happens,” it’s “you denied the thing you meant to allow.” That said, parsing terminal screen contents and relying on a pointer glyph still feels a little fragile to me. It’s clever, but clever is not the same as durable.
What I’d actually try first, if I were building this, is to avoid the dialog entirely by changing the workflow so the approval boundary happens less often, or at least is surfaced in a place I can hook more reliably than Terminal UI scraping. Maybe that’s not possible here. Maybe this is exactly the kind of situation where the least bad option is a hacky daemon. But I’d still treat it like a temporary glue layer, not something to forget about once it “works.”
The other thing I appreciate is the honesty about the rough edges: TCC hanging without a prompt, one-off AppleScript errors getting swallowed and retried, the fact that the end-to-end confirmation is still against a fake dialog screen. That last caveat matters. It’s the difference between “I have a neat automation story” and “I have something I trust enough to leave running.” Those are not the same thing, and the article doesn’t pretend they are.
Reference: 5 Pitfalls I Hit Building a Daemon That Auto-Approves Claude Code's Computer Use Dialog
