Feature Request: Make Companion (Cinder) Output Programmatically Accessible

Summary

The companion (Cinder) generates responses by calling the Claude API — it costs tokens and often produces genuinely useful observations. However, its output is display-only: rendered as a speech bubble in the TUI, never persisted, and not accessible to hooks, logs, or any programmatic workflow. This means companion insights are effectively write-only — seen once, then gone.

I built a complete workaround (cinder-capture) to solve this for myself, but the experience of building it revealed that this gap should be solved at the product level, not by individual users reverse-engineering terminal rendering.

Current Behavior

• Companion responses are rendered as box-drawing bubbles (` ╭──╮ / │ text │ / ╰──╯ `) in the terminal UI
• The conversation JSONL log contains only a companion_intro initialization marker — actual companion responses are not logged
• No hook event fires when the companion speaks
• No API or file exposes companion output

What I Tried (and Hit Walls)

| Approach | Result |
|---|---|
| Chrome DevTools Protocol (CDP) | Blocked — Electron uses Ed25519 authentication, cannot attach externally |
| Electron asar modification | Blocked — integrity verification prevents patching the app bundle |
| JSONL conversation log | Only companion_intro marker exists; companion text is never written |

What Actually Worked (Proof of Concept)

After the above dead ends, I built cinder-capture — a pipeline that:

1. Stop hook triggers a background Python script (returns in ~53ms, non-blocking)
2. PowerShell + UIAutomation reads raw text from the Windows Terminal TermControl via TextPattern
3. Regex parser extracts the bubble content from box-drawing characters
4. JSONL log stores timestamped companion messages with deduplication
5. UserPromptSubmit hook reads the latest log entry (if <120s old) and injects it as additionalContext

This works — Claude now "hears" what Cinder said and can factor it into responses. But this approach is:

• Platform-specific (Windows Terminal + UIAutomation; won't work on macOS/Linux without equivalent accessibility APIs)
• Fragile (depends on terminal text rendering, box-drawing character format, screen buffer state)
• Unreasonably complex for what should be a simple data flow

Proposed Solution

Any of these would solve the problem at the right layer:

Option A: Log companion output to JSONL (minimal change)

Write companion responses to the existing conversation JSONL alongside user/assistant messages. This alone would let hooks and external tools access the data.

Option B: Add a companion hook event

Fire a hook event (e.g., CompanionResponse) with the companion's text as payload. This fits naturally into the existing hook system and gives users full control over what to do with it.

Option C: Expose via MCP or context API

Make the most recent companion message available in the hook context object, similar to how additionalContext works today.

Option A is probably the smallest diff with the most impact. But any of these would eliminate the need for screen-scraping workarounds entirely.

Why This Matters

The companion is already good — it catches things, offers different angles, and sometimes flags issues the main assistant missed. But right now its value is capped by the fact that it's ephemeral. Users can't:

• Build workflows around companion observations
• Log companion insights for review
• Let the main assistant consider what the companion said
• Reference past companion comments

Beyond the "latest message" use case, there's a deeper value in companion history as a longitudinal signal. Over the course of a session, the companion may repeatedly flag the same concern, shift its focus as the work evolves, or catch something early that only becomes relevant later. With persistent logs, users could review the companion's observation trail across an entire session — patterns that are invisible when each bubble disappears after a scroll. Right now, even my workaround only injects the most recent message; the full history is logged but underutilized, precisely because there's no native way to surface it.

Every user who discovers the companion's potential currently faces the same three dead ends I did. Most will give up. Making companion output accessible turns a nice-to-have UI element into a genuine part of the AI-assisted workflow.

References

• Working proof of concept: cinder-capture (Python + PowerShell, Stop/UserPromptSubmit hooks)
• Technical write-up of the capture pipeline is in the repo README

---

I built the workaround because I didn't want to waste the tokens Cinder spends. But the real fix belongs in the product, not in every user's dotfiles.

And for what it's worth, while drafting this proposal, Cinder itself commented: "黑盒裡塞了金礦，卻只給你一根稻草" — "There's a gold mine locked in a black box, but all you get is a single straw." Even the companion knows its own output deserves better.