The fix I talked myself out of

I built a WebDriver harness for Greenhouse a while back so an agent could click through the real app during verification, real IPC, real SQLite, no mocks. It works well. It also has an annoying side effect: every time a session opens, the app’s window pops to the front of my screen and steals my keyboard focus. If I’m typing anything else at that exact moment, those keystrokes go into the wrong window.

I put an agent on fixing it, and its first research pass talked itself out of fixing it at all. Tauri’s window config has a focus field, but that’s a known, unresolved limitation upstream in the windowing library Tauri sits on: setting it to false doesn’t reliably stop macOS from activating the app. Fine, dead end, expected. The conclusion from there was that the only remaining option was reaching past Tauri’s supported API into raw Cocoa calls, which felt too risky to recommend. What came back to me was a whole “don’t build this” writeup with that reasoning, plus a consolation prize of warning me before a session grabs focus.

My response was blunt: that’s a bad solution, it defeats the point of automation. “Warn me before I get interrupted” isn’t a fix, it’s just scheduling the interruption. That pushback is what forced a second look instead of a defense of the first answer.

The second pass found the first one wrong on both counts. tauri::App::set_activation_policy is a real, already-shipped Tauri API, not some risky FFI workaround. It’s just documented on the wrong type (App, not the more commonly used AppHandle), which is probably why the first pass missed it. And the “risky to automation” worry evaporated after actually checking how the WebDriver plugin drives the app: everything happens by evaluating JavaScript inside the webview and passing results back over IPC. None of it touches real OS-level clicks or keystrokes. An app that doesn’t grab the Dock or auto-activate has no way to interfere with that, because that mechanism was never in the path to begin with.

The fix ended up being one line, gated behind the same debug-only flag that already turns the automation server on. I didn’t just trust the reasoning either: the verification recorded which app was frontmost before opening a WebDriver session, opened one, checked again immediately after (unchanged), and then ran the full capture-flow e2e script against the same build to confirm automation still worked exactly as before.

The lesson isn’t really about Tauri’s activation policy. It’s that the first “this isn’t worth building” conclusion was built on two unverified assumptions stacked on top of each other - no first-class API exists, and building one would be risky - and both were wrong, but they sounded reasonable enough that the digging stopped. Rejecting the conclusion outright, rather than nitpicking the reasoning, was what actually got the investigation reopened.