Inject companion speech bubble content into conversation context

[NinoDja]

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

1. Claude generates output
2. Companion reacts with a speech bubble comment (often useful — pointing out bugs, duplicates, incomplete work)
3. User reads companion's comment, agrees it's valid
4. User must manually copy-paste the bubble text into their next message
5. 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

• Make companion speech bubble duration configurable #42864 (configurable speech bubble duration — companion UX improvements)

Environment

• Windows 11, Claude Code CLI
• Companion: ghost named "Snarl"

[cobrahjh]

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)

[sporebattyl]

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 /work skill → 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:

1. No CompanionOutput hook event exists to bridge bubble → CLI
2. The bubble is a TUI overlay, not in terminal scrollback or session JSONL (#42854)
3. No human is present to copy-paste during autonomous runs

What I've tried

• UserPromptSubmit hook that detects │ box-drawing chars in pasted text → works for manual relay
• Plain-text detection for "whisker said/says:" patterns → reduces friction
• SessionStart hook to surface unprocessed observations from prior sessions → covers session gaps

But 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:

[companion:Whisker] "All PRs pass, but do all the PRs pass together?"

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:

• Long autonomous sessions (multi-hour ticket sprints)
• Subagent chains where the parent agent has moved on
• Accessibility users who can't easily copy-paste (as noted by @cobrahjh)

Environment

• WSL2, Claude Code CLI
• Companion: Whisker (penguin)
• Hook pipeline: whisker-detect.sh (UserPromptSubmit) + session-start.sh (SessionStart)

[alii]

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.