Repository navigation
Description
Use Case
I run a fleet of coding agents (Claude Code, Codex, OpenCode, Qwen Code, Pi, Antigravity) over one shared memory and instruction layer. hindsight-coding-agents is the memory plugin on every harness that has an installer target, wired from a registry so that every harness gets the same recall and retain. Muse Code (muse 1.4.7) is in trial as a daily harness, both through its own CLI and through its ACP bridge (muse-code-acp 0.10.0). My policy is that a harness without the shared memory is not usable, so Muse currently sits in a red cell.
Problem Statement
hindsight-coding-agents install (0.8.0) has no target for Muse Code. The targets today are opencode, opencode2, kilo, pi, prime-agent, claude-code, codex, antigravity-cli, devin-cli, cursor-cli, copilot-cli, grok-build, qwen-code, kimi-code, cline-cli, dcode, dsh, factory-droid, zcode and traecode. Without a harness there is no inject hook, no retain hook and no transcript reader, so Muse sessions start with no recall and leave nothing behind.
How This Feature Would Help
Muse sessions would inject and retain like the other harnesses, into the same memory bank, and the fleet-side wiring check could mark the cell wired instead of upstream.
Proposed Solution
A muse-code harness. What Muse 1.4.7 exposes, measured on my machine (Fedora Linux):
- Config:
~/.config/muse/settings.json, flat JSON with aschema_version.mcpServersis a known member and takes stdio entries (command,args;type: "stdio"is tolerated) and streamable-HTTP entries (url);muse mcp login <server>handles OAuth servers. Unknown top-level members are named at startup, not rejected. Muse also reads Claude Code's personal rules and skills directory at startup ("Including your Claude Code personal rules and N skills"), so a Claude-styleSKILL.mdis already picked up. - Plugins:
muse plugins install <path> [--scope user|project]installs a bundle with runtime capabilities, including hooks (muse plugins hook test <plugin-id>:<hook-id> --fixture <path>), per-capability approve/reject, and marketplace sources. This looks like the natural home for inject/retain, the way the opencode plugin works. - Sessions: an MSP event journal under
~/.local/share/muse/sessions/.msp-view-v1/<session-id>/(binaryjournal-*.bin,HEAD.json, an index).muse exportwrites a transcript file andmuse traceinspects a recorded session, so a transcript reader could go throughmuse exportrather than parsing the journal.muse exec --jsonstreams JSONL lifecycle events for headless runs. - Headless surfaces:
muse exec,muse serve(MSP over stdio) and the ACP bridgemuse-code-acp. - The MCP server would also need a
HINDSIGHT_MCP_HARNESSvalue for Muse.
I can test a branch on this machine against real Muse sessions and report back.
Alternatives Considered
- Wiring only the Hindsight MCP server into Muse's
mcpServers: tools without recall injection or retain, andmcp-server.jswants a knownHINDSIGHT_MCP_HARNESS, so even that waits on a harness id. - Driving the existing Claude Code hooks from a Muse plugin hook: the plugin capability contract is not documented enough for me to judge whether the payloads match.
Priority
Important - affects my workflow
Additional Context
Muse Code 1.4.7 (1.4.7-R6101.1), muse-code-acp 0.10.0, @vectorize-io/hindsight-coding-agents 0.8.0, Fedora Linux. Happy to run any probe you need on the Muse side.
@superbiche · user · drafted with Claude Fable 5.1.
Activity