Claude Opus 4.7 + ultracode: 50min/37% budget burned, total failure on Chrome Native Messaging integration on Win11
Summary
I asked Claude Opus 4.7 with the ultracode multi-agent workflow to wire up a Chrome right-click context menu that spawns a Claude Code session with a /paper slash command pre-filled. The slash command and skill pieces were trivial and worked. The Chrome integration burned roughly 50 minutes and ~37% of my token budget and ended in total failure, with the workflow itself crashing partway through.
I want to flag both the technical dead-ends Claude walked into and the planning/harness failures that made it expensive.
What Claude tried (in order)
- Windows custom URL protocol (
claudecode://). HKCU registration was silently ignored by Windows 11 26200. HKLM registration auto-elevated via UAC, and the elevated launcher then couldn't see the user's PATH / non-elevated file locations. Dead end. - Chrome Native Messaging with a
.bat/.cmdhost wrapper. Chrome rejected it:Specified native messaging host not found. - Real C#
.exehost compiled withcsc.exe. I wrote a self-test that piped Chrome's exact stdin length-prefixed protocol through the binary end-to-end — it passed. The host is demonstrably correct. - Full integration attempt with the working
.exe+ a byte-perfect manifest modeled oncom.anthropic.claude_browser_extension(which works on the same machine) + correct HKCUNativeMessagingHostsregistration + matching extension ID inallowed_origins+nativeMessagingpermission inmanifest.json+ full Chrome restart (51 processes killed) + HKLM fallback registration. Chrome still returnedSpecified native messaging host not found. Never resolved.
Machine: Windows 11 Pro 10.0.26200, Chrome 64-bit at C:\Program Files\Google\Chrome\Application\chrome.exe, extension loaded as unpacked in Profile 1 (not Default). Other native messaging hosts on the same machine (Anthropic's own, ShareX, Microsoft, Apple) work fine, so this is not a global Chrome/registry problem.
Workflow failure
Mid-run, the ultracode workflow died with subagent completed without calling StructuredOutput (after 2 in-conversation nudges). About 46 minutes and ~250k tokens of subagent work were thrown away with no surfaced output. The structured-output retry mechanism is not robust enough — agents are dropping the final tool call even with two nudges.
Model/harness failures Claude should own
- No backtracking to a simpler architecture. After URL protocols failed, the obvious move was a tiny localhost HTTP server the extension POSTs to. Instead Claude doubled down on Native Messaging across four sub-attempts. Sunk-cost iteration over re-planning.
- Pushed testing onto me. Almost every probe was "run this and tell me what happens" instead of
Bash-driven verification. Five-second checks turned into multi-minute round-trips. - No diagnostic visibility into Chrome's side. When Chrome says
host not foundbut the registry key, manifest path, file ACLs, extension ID, andallowed_originsall check out, Claude has no way to ask Chrome why. There is presumably achrome://-internal log or a--enable-logging --v=1path it could have pointed me at much earlier.
Concrete suggestions
- Ship a Native Messaging diagnostic recipe in the Claude Code docs/skills — the exact
chrome.exe --enable-logging --v=1invocation, where the log lands, and the strings to grep for. The current debugging loop is blind. - Make the StructuredOutput nudge mechanism resilient: if a subagent fails to emit structured output after N nudges, fall back to parsing the last assistant message rather than discarding the entire run. Losing 250k tokens to a missing tool call is brutal.
- Bake an "architecture-reset" reflex into long-running coding workflows: after 2 failed attempts at the same integration mechanism, force a step back and enumerate alternatives before continuing to patch.
- Prefer in-harness verification (
Bash/PowerShell) over asking the user to run things, especially in ultracode where round-trips compound across agents.
Happy to share full transcript or a minimal repro of the host not found case if useful.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗