ClaudeCode agents. Its sole purpose is to monitor permission prompts and click "Allow" so my autonomous workflows don't stall at 2 AM while I'm asleep. The entire value proposition is reliability: when the agent needs a human, HELM stands in.
On July 23rd, I realized it hadn't actually approved a single thing since July 3rd.
For twenty days, it ran continuously. Its self-test reported Self-check OK (8/9)
every single time. The logs were filled with what looked like successful approvals. In reality, it had clicked nothing. This was a total system failure across multiple layers, and there are some serious lessons here for anyone building an AI workflow or LLM agent.
The "Invisible" UI Problem #
Claude Desktop is an Electron app, meaning it uses Chromium. Chromium's accessibility tree is lazy; it only builds the tree for renderer content if it thinks an assistive technology client is listening. Around July 3rd, it decided nobody was listening.
The result? HELM could still see the native shell—the window chrome, the sidebar, the minimize button. Everything looked alive. But the conversation pane, where the "Allow" button actually lives, vanished from the tree entirely. It wasn't moved or renamed; it was just gone. I only found this by dumping every UIA control in the window and realizing that out of 641 nodes, zero were content.
The Health Check Trap #
My health check was lying to me. I had a category for "non-critical" errors, and the core capability of the product—actually seeing the button—was filed under advisory. It reported 8/9 checks passed, and I ignored the one failure.
I've since updated the logic. If any check fails, the tray no longer says "OK"; it prints Self-check DEGRADED
and explicitly names the failure. If you have "non-critical" categories in your monitoring, check them immediately.
Visibility vs. Interactivity #
After fixing the blackout, I released v1.0.24. The logs showed
content pane IS exposed
and Self-check OK (9/9)
. But it still couldn't approve anything.I learned the hard way that "can it see" and "can it click" are two different questions. Claude's actual button label is a concatenated string: 'Allow once 2 Ctrl +Enter'
. My matcher was looking for exactly "Allow once"
or "Allow"
.
Because it didn't find an exact match, it fell back to a regex ^allow
, which matched the question heading of the dialog (e.g., 'Allow Claude to use create scheduled task...'
). HELM was clicking the question. Clicking a question does nothing, but since the Invoke()
method didn't throw an error, the code logged it as a success.
I ended up with logs showing thousands of "approvals" that were actually just the bot clicking a piece of text over and over again. This is a great reminder for anyone doing a deep dive into UI automation: never trust a successful method return as proof of a successful business outcome.
Next Spotify & YouTube Automation: Local Deployment Guide →