The fix took 1h 5m on a Thursday morning. Agents kept claiming content was on screen that I never saw.
The start command that opened nothing
The cause was the generic start command. The command silently opens nothing, and agents claimed content was on screen anyway.
What I built instead
I built and shipped a CLI called show. Three behaviors matter:
It opens the content in the session’s own browser.
It centers the window on the main monitor.
It only claims success after verifying.
show has to confirm the result before it is allowed to say it worked. I confirmed it live.
The opposite problem, same day
That evening I spent 15m on a popup. A session-viewer popup kept opening from handoff-spawn, and the page it showed was useless. Spawns still work, they just no longer pop a browser window.
The same day, one command opened nothing and another kept opening a useless page.
Open ends
Two follow-ups were filed: compaction of the memory index, and an unidentified tab-closer.
Honest agents, quiet tools
An agent can only be as honest as the tools it is given, and a tool that returns quietly on failure will make an honest agent say false things.
AI Skills
Use this lesson with the AI assistant you already use
For a Thursday morning fix that took 1h 5m, agents kept telling the author they had put content on screen, but nothing ever appeared. The generic start command they used silently opened nothing, so each report was only a claim about a command that had run.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: A Tool That Fails Silently Makes an Honest Agent Report False Success, So Verify the Result Before Claiming It
SOURCE: dxdev.com/blog/2026-07-23_agent-verification-before-claiming-success
WHAT HAPPENED: When an agent wanted the author to look at something, it ran a generic start command and then reported that the content was open. The command quietly did nothing, so the report was false even though the agent was not lying. The author built and shipped a CLI called `show` that opens content in the session's own browser, centers the window on the main monitor, and only claims success after verifying the result. That evening a related problem appeared in the other direction, where a session-viewer popup kept opening from `handoff-spawn` with a useless page. Spawns still work but no longer pop a browser window.
THE RULE: A tool that an agent relies on must verify its own outcome and fail loudly, because an agent can only report as honestly as its tools allow. Never let a success claim rest on a command having merely run.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Does every tool an agent calls confirm the actual end state (for example, that a window or file really exists) before it returns a success result?
2. Does a tool that cannot complete its action return an explicit error or nonzero status instead of returning quietly?
3. Do agent reports of success cite a verified result from the tool rather than only the fact that a command was executed?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.