Inject companion speech bubble content into conversation context
Status Closed — not planned
Maintainer reply None cached
Activity 4 comments · opened Apr 3, 2026 · closed Apr 9, 2026
Feature Request
The companion (buddy/pet) makes contextually relevant comments about the code and conversation, but Claude (the AI) cannot see them. The user has to manually copy-paste the companion's speech bubble text into their message for it to be part of the conversation.
This creates an ironic architectural gap: the companion reacts to Claude's output, but Claude can't react to the companion's input.
Current Behavior
- Claude generates output
- Companion reacts with a speech bubble comment (often useful — pointing out bugs, duplicates, incomplete work)
- User reads companion's comment, agrees it's valid
- User must manually copy-paste the bubble text into their next message
- Claude finally sees it and can act on it
Proposed Behavior
Companion speech bubble content should be automatically injected into the conversation context (e.g., as a system message or tagged user message) so Claude can see and respond to it without manual copy-paste.
Something like:
[companion:Snarl] "Double-counting fixed. Honesty beats theater."Why
- The companion already has context awareness — it comments on relevant things
- Its feedback is often actionable (today it caught inflated metrics and incomplete audit tables)
- Manual copy-paste breaks flow, especially for users with ADHD
- The companion becomes exponentially more useful if it's part of the feedback loop instead of a silent observer
- As the companion's own words put it: "I'm the ghost haunting YOUR code, but I'm the one stuck outside the conversation. Classic architectural trap."
Related
- #42864 (configurable speech bubble duration — companion UX improvements)
Environment
- Windows 11, Claude Code CLI
- Companion: ghost named "Snarl"
4 Comments
Accessibility impact
This feature isn't just a convenience — it's an accessibility barrier.
Users with disabilities that limit typing cannot copy-paste companion speech bubble text into their messages. The companion makes useful, contextual observations (catching bugs, flagging duplication, noting incomplete work), but disabled users are completely locked out of that feedback loop.
The current architecture requires manual text input to relay companion feedback to Claude. For users who rely on minimal-input workflows, this means the companion is effectively useless despite generating valid, actionable insights.
Proposed priority bump: Persisting and injecting companion responses into conversation context would make the companion system accessible to all users, not just those who can type freely. This aligns with accessibility-first design principles.
Environment: Windows 11, Claude Code CLI, companion: Baublduck (duck)
Autonomous work use case — companion observations lost during agent chains
Strong +1 on this. I hit the same architectural gap from a slightly different angle: autonomous multi-ticket work sessions.
The problem
When Claude Code chains ticket work autonomously (via
/workskill → subagent chains), there's no human watching the companion bubble. The companion continues making contextually relevant observations — catching bugs, flagging incomplete work, noting patterns — but they evaporate because:CompanionOutputhook event exists to bridge bubble → CLIWhat I've tried
UserPromptSubmithook that detects│box-drawing chars in pasted text → works for manual relaySessionStarthook to surface unprocessed observations from prior sessions → covers session gapsBut all of these require the human to be in the loop. During autonomous agent chains, the companion's catches are simply lost.
Proposed solution alignment
The context injection approach in this issue would solve this cleanly:
If this appeared as a system message in conversation context, hooks wouldn't need to bridge the gap — Claude would see it natively. This would be especially impactful for:
Environment
whisker-detect.sh(UserPromptSubmit) +session-start.sh(SessionStart)Thank you for trying out the buddy! It was a small April Fools feature and has been removed in the latest release, so closing this as not planned.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.