app

Adom Hydrogen

Public Made by Adom

by adom

The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.

Overview Files Skills Packages Releases Dependencies Issues11 Breadcrumbs Pull Requests1 Activity
Closed general

/claude/send DOM injector is stale against current Claude Code (No chat input found); open-with-message + submit works

John Lauer · 8d ago ·closed by John Lauer

Type: Bug (found 2026-08-02 during the Settings-driven theme gallery)

POST /claude/send {message} fails with {"error":"inject failed","inject":{"error":"No chat input found in any VS Code context. Claude Code panel may not be open."}} even with a Claude chat tab open and its input visible. The DOM injector's selectors predate the current Claude Code build (input is a contenteditable inside the webview, not the textarea the injector looks for). /claude/inject-message shares the injector, so it is presumably broken too.

Workaround that works today (used for the gallery): POST /claude/open-with-message {message} (command-based prefill, no DOM injection) followed by POST /claude/submit.

Related nuance worth knowing when fixing: chats opened via the command path get Claude's fullEditor styling (chat body = editor.background), while user-path chats (session history) paint sideBar.background. Details measured on the adom-theme page README validation section.

1 Reply

John Lauer · 8d ago

Fixed and verified live (2026-08-02, commits c9af261c + 755b2de6).

TWO root causes, both required:

  1. Stale selector: claude_inject_message and claude_submit hardcoded div[role="textbox"][aria-label="Message input"] while only claude_type_and_submit carried the robust multi-selector finder. Extracted the finder into a shared CLAUDE_INPUT_FINDER_JS const and pointed all of them at it (contenteditable vs textarea handling + full Enter key sequence fallback).
  2. The context-walk predicate: claude_inject_message matched any result containing "ok", so the walk short-circuited on the FIRST context answering ok:false (the workbench root, which legitimately has no chat input) and never reached the webview context that does. claude_type_and_submit had this same bug fixed earlier with a comment describing it exactly; the inject path was never updated. Now requires "ok":true.

Verification: POST /claude/send with a chat open -> inject ok (contextIndex 18), submit ok (method "clicked", the real send button), message rendered in the conversation and Claude replied. Screenshot on file.

Diagnostic tip that cracked it: GET /claude/contexts (the census, collect-all) SAW the chat context while /claude/send (first-hit walk) reported none - when those two disagree, suspect the hit predicate, not the selectors.

Log in to reply.