Skip to content

Coding agents: add a Muse Code (muse) harness #5637

Open

Description

@superbiche

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 a schema_version. mcpServers is 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-style SKILL.md is 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>/ (binary journal-*.bin, HEAD.json, an index). muse export writes a transcript file and muse trace inspects a recorded session, so a transcript reader could go through muse export rather than parsing the journal. muse exec --json streams JSONL lifecycle events for headless runs.
  • Headless surfaces: muse exec, muse serve (MSP over stdio) and the ACP bridge muse-code-acp.
  • The MCP server would also need a HINDSIGHT_MCP_HARNESS value 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, and mcp-server.js wants a known HINDSIGHT_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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions