Harnesses — Signet Docs

Docs / Reference

Harnesses

AI platform integrations and harness configuration.

Harnesses

Harnesses are the AI platforms and tools that Signet integrates with. Some are external platforms reached through connectors. Forge is the first-party native harness and the reference runtime implementation for the Signet runtime contract.

Path note: $SIGNET_WORKSPACE means your active Signet workspace path. Default is ~/.agents, configurable via signet workspace set <path>.


How Harness Sync Works

When you change $SIGNET_WORKSPACE/AGENTS.md:

  1. The Daemon file watcher detects the change (within 2 seconds)
  2. The daemon reads the new content
  3. It prepends an auto-generated header identifying the source
  4. It writes the result to each configured harness location

The header looks like this:

# CLAUDE.md
# ============================================================================
# AUTO-GENERATED from $SIGNET_WORKSPACE/AGENTS.md by Signet
# Generated: 2025-02-17T18:00:00.000Z
# 
# DO NOT EDIT THIS FILE - changes will be overwritten
# Edit the source file instead: $SIGNET_WORKSPACE/AGENTS.md
#
# Related documents:
#   - $SIGNET_WORKSPACE/SOUL.md (Personality & tone)
#   - $SIGNET_WORKSPACE/MEMORY.md (Working memory context)
#   - $SIGNET_WORKSPACE/agent.yaml (Configuration & settings)
#
# Memory commands: /remember <content> | /recall <query>
# ============================================================================

You can also trigger a manual re-sync:

curl -X POST http://localhost:3850/api/harnesses/regenerate

Forge

Forge is Signet’s native terminal harness. Unlike external harness integrations, it does not need hook/config patching because it speaks to the daemon directly as the host runtime.

Management surface

Forge remains a separate product command:

forge

Signet can also manage Forge installs directly:

signet forge install
signet forge update
signet forge status
signet forge doctor

Managed installs place the binary in ~/.config/signet/bin. Add that directory to your PATH if you want forge available in a normal shell.

Managed binary downloads currently support macOS arm64, macOS x64, Linux x64, and Linux arm64. On other platforms, install Forge from source or use a local standalone build.

Install/update commands prompt for an explicit development warning acknowledgement. For automation:

signet forge install --yes
signet forge update --yes

Runtime role

  • first-party native harness
  • reference implementation of the Signet runtime contract
  • direct daemon client for memory, hooks, skills, secrets, and MCP

Forge is still represented as a harness id (forge) in Signet config, setup detection, and dashboard surfaces.

Lossless Working Memory Fidelity (Closure Wave)

This matrix is the source of truth for closure-wave fidelity and degraded mode expectations across harness paths.

Harness pathPrompt retrieval orderThread-head continuityCompaction artifact persistenceForced post-event MEMORY refresh
TS daemon (primary)hybrid -> temporal-fallback -> transcript-fallbackyesyesyes (session-summary + compaction-complete)
daemon-rs shadowhybrid-style scoped recall with temporal/transcript fallbackyes (agent-scoped retrieval path)partial (hook route persistence only)degraded (full event-driven refresh parity follows rust cutover wave)

Degraded mode rules:

  • When a harness/runtime path cannot emit every lifecycle event, Signet must document the missing surface explicitly instead of implying full parity.
  • Compaction/session-summary forced-refresh guarantees are currently full in TS daemon and degraded in daemon-rs shadow path.
  • Prompt-time anti-bleed scoping remains mandatory across all paths.

Claude Code

Claude Code is Anthropic’s official CLI for Claude. It reads configuration from ~/.claude/.

Files managed by Signet

FileDescription
~/.claude/CLAUDE.mdAuto-synced from $SIGNET_WORKSPACE/AGENTS.md
~/.claude/settings.jsonHook configuration (written once during setup)

Memory hooks

Signet writes Hooks to ~/.claude/settings.json that fire at session lifecycle events. The hooks call the Signet CLI, which routes requests through the daemon HTTP API:

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "signet hook session-start -H claude-code --project \"$(pwd)\"",
        "timeout": 3000
      }]
    }],
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "signet hook user-prompt-submit -H claude-code --project \"$(pwd)\"",
        "timeout": 2000
      }]
    }],
    "SessionEnd": [{
      "hooks": [{
        "type": "command",
        "command": "signet hook session-end -H claude-code",
        "timeout": 15000
      }]
    }]
  }
}

SessionStart — loads memories and context, outputs them as text that Claude Code injects into the system prompt.

UserPromptSubmit — optionally loads per-prompt context (lighter weight than session start).

SessionEnd — automatically saves a session summary to memory.

Using /remember and /recall

In Claude Code sessions, use these commands directly:

/remember nicholai prefers bun over npm
/recall coding preferences

These work via the built-in skills in $SIGNET_WORKSPACE/skills/. The skill instructions tell Claude how to call the Signet daemon API.

MCP Tools

Claude Code also gets native MCP tool access to Signet memory via the signet-mcp stdio server, registered in ~/.claude/settings.json:

{
  "mcpServers": {
    "signet": {
      "type": "stdio",
      "command": "signet-mcp",
      "args": []
    }
  }
}

This gives Claude Code direct access to memory_search, memory_store, memory_get, memory_list, memory_modify, and memory_forget tools.

Prerequisites

  • Claude Code installed and in PATH
  • ~/.claude/ directory exists

Codex

Codex is OpenAI’s terminal coding agent (codex-rs). Signet integrates with Codex using its native hook system (hooks.json) for full lifecycle memory — including per-prompt recall on every user turn. Signet also registers as an MCP server so Codex can call signet_remember and signet_recall as native tools.

Files managed by Signet

FileDescription
~/.codex/hooks.jsonNative Codex hooks — SessionStart, UserPromptSubmit, Stop
~/.codex/config.tomlMCP server registration ([mcp_servers.signet])
~/.codex/skillsSymlink to $SIGNET_WORKSPACE/skills

How it works

  1. Codex reads ~/.codex/hooks.json at startup and registers three hooks.
  2. On session start, Codex fires SessionStart → calls signet hook session-start -H codex → Signet returns identity + memories as additional_context injected into the model’s context window.
  3. On every user prompt, Codex fires UserPromptSubmit → calls signet hook user-prompt-submit -H codex → Signet returns per-prompt recalled memories as additional_context. This is blocking — Codex waits for the hook before sending to the model.
  4. On session end, Codex fires Stop → calls signet hook session-end -H codex → Signet extracts memories from the transcript.
  5. The MCP server exposes memory_store, memory_search, and other memory tools that Codex can invoke directly during sessions.

Codex matches the session-start, prompt-submit, and session-end path, but it does not currently expose the same compaction lifecycle fidelity as Claude Code or OpenCode.

Supported hooks

HookSupported
session-startyes — identity + memories via additional_context
user-prompt-submityes — per-prompt recall via additional_context
session-endyes — transcript extraction via Stop hook

MCP tools

When the Signet MCP server is registered, Codex gains access to these tools (namespaced as mcp__signet__*):

  • memory_store — save a memory
  • memory_search — hybrid recall (vector + keyword)
  • memory_list — list recent memories
  • memory_modify — update existing memory
  • memory_forget — delete a memory

Extraction provider

Codex can be selected as the extraction provider in agent.yaml. When set, the pipeline uses the Codex CLI (similar to the claude-code provider) to run extraction and decision passes against Codex’s configured model rather than a local Ollama instance.

Prerequisites

  • Codex (codex-rs) installed and in PATH
  • Signet daemon running (signet daemon start)

OpenCode

OpenCode is an open-source AI coding tool. Signet integrates via a bundled plugin and AGENTS.md sync.

Files managed by Signet

FileDescription
~/.config/opencode/AGENTS.mdAuto-synced from $SIGNET_WORKSPACE/AGENTS.md
~/.config/opencode/plugins/signet.mjsBundled plugin providing memory tools

Plugin Bundle

During signet install, the connector writes a self-contained signet.mjs file to ~/.config/opencode/plugins/ and registers ./plugins/signet.mjs in the OpenCode config so the runtime loads it consistently at startup.

The plugin is built from @signet/opencode-plugin source and bundled into a single ESM file at build time (stored as a string constant in plugin-bundle.ts). This means the plugin has no external dependencies at runtime.

The previous approach (memory.mjs in the OpenCode root directory) is considered legacy. The connector automatically migrates away from it during install by deleting the old file and scrubbing any memory.mjs references from the config’s plugin or plugins arrays.

Config File Detection

The connector searches for an OpenCode config file in this order:

  1. ~/.config/opencode/opencode.json
  2. ~/.config/opencode/opencode.jsonc
  3. ~/.config/opencode/config.json

The first one found is used. If none exist, opencode.json is created as the default. JSONC files (with // comments and trailing commas) are parsed correctly — the connector strips comments and trailing commas before parsing.

MCP Tools

OpenCode also gets MCP tool access via a local server entry registered in the config file during install:

{
  "mcp": {
    "signet": {
      "type": "local",
      "command": ["signet-mcp"],
      "enabled": true
    }
  }
}

The plugin handles lifecycle hooks; MCP provides on-demand memory tools.

Supported hooks

HookSupported
session-startyes
user-prompt-submityes
pre-compactionyes
compaction-completeyes
session-endyes

Prerequisites

  • OpenCode installed
  • ~/.config/opencode/ directory exists

OpenClaw

OpenClaw is the flagship harness for the lossless working-memory model. The plugin path gives the closest match to the full LCM runtime, while the legacy hook path remains compatibility-only.

Files managed by Signet

LocationDescription
$SIGNET_WORKSPACE/AGENTS.mdSource of truth (OpenClaw reads workspace directly)
$SIGNET_WORKSPACE/hooks/agent-memory/Hook handler directory
~/.openclaw/openclaw.jsonWorkspace configuration

Workspace configuration

Signet sets OpenClaw-family configs to your active Signet workspace. Change it with:

signet workspace set ~/.openclaw/workspace

Common compatible workspace targets include:

  • ~/.openclaw/workspace
  • ~/.clawdbot/workspace
  • ~/clawd
  • ~/.moltbot/workspace

OpenClaw config value:

{
  "agents": {
    "defaults": {
      "workspace": "$SIGNET_WORKSPACE"
    }
  }
}

OpenClaw checks these config locations (in order):

  • ~/.openclaw/openclaw.json
  • ~/.clawdbot/clawdbot.json
  • ~/.moltbot/moltbot.json

@signetai/adapter-openclaw

The adapter package provides a full lifecycle integration:

import createPlugin from '@signetai/adapter-openclaw';

const signet = createPlugin({
  enabled: true,
  daemonUrl: 'http://localhost:3850'  // default
});

Session start — inject memories into system prompt:

const result = await signet.onSessionStart({
  harness: 'openclaw',
  sessionKey: session.id
});
// result.inject → prepend to system prompt

Pre-compaction — get summary guidelines:

const guide = await signet.onPreCompaction({
  harness: 'openclaw',
  messageCount: messages.length
});
// guide.summaryPrompt → use as compaction instruction

Compaction complete — save the generated summary:

await signet.onCompactionComplete({
  harness: 'openclaw',
  summary: generatedSummary,
  sessionKey: session.id
});

When OpenClaw only exposes compaction metadata to the plugin hook, the runtime may read the latest compaction summary back from sessionFile before calling the daemon so the temporal DAG still receives the real artifact.

Manual memory operations:

await signet.remember('nicholai prefers bun', { who: 'openclaw' });
const results = await signet.recall('coding preferences');

MEMORY.md synthesis

The daemon synthesis worker is the primary runtime path for keeping MEMORY.md current. OpenClaw may still drive synthesis on a schedule by:

  1. Calls GET /api/hooks/synthesis/config to check if synthesis should run
  2. Calls POST /api/hooks/synthesis to get the synthesis prompt
  3. Runs the prompt through the configured model
  4. Posts the result to POST /api/hooks/synthesis/complete

Both paths write through the same merge-safe head record, so the rendered MEMORY.md stays shared across harnesses instead of becoming OpenClaw-specific.

Hooks directory

During setup, Signet creates $SIGNET_WORKSPACE/hooks/agent-memory/ with:

  • HOOK.md — hook documentation
  • handler.js — event handler (for older hook-based integration)
  • package.json — package metadata

Package Distinction: adapter vs connector

Signet provides two separate packages for OpenClaw integration:

@signet/connector-openclaw

Purpose: Setup and installation

This is a setup-time package that:

  • Patches OpenClaw config files (openclaw.json, clawdbot.json, moltbot.json)
  • Sets agents.defaults.workspace to your active Signet workspace
  • Enables the signet-memory internal hook entry
  • Installs hook handler files under $SIGNET_WORKSPACE/hooks/agent-memory/

Installed during signet setup when OpenClaw is selected.

@signetai/adapter-openclaw

Purpose: Runtime plugin

This is a runtime plugin that OpenClaw loads to:

  • Call the Signet daemon API for /remember, /recall operations
  • Handle lifecycle hooks (session start, compaction, etc.)
  • Inject memories into the system prompt

Has a peer dependency on openclaw — only usable within the OpenClaw process.

Adding a New Harness

To integrate Signet with a harness not listed here:

  1. Identity sync — simply watch for $SIGNET_WORKSPACE/AGENTS.md changes and copy the content to wherever your harness reads agent instructions.

  2. Memory access — call the daemon’s HTTP API:

    • POST /api/memory/remember to save memories
    • POST /api/memory/recall to search memories
  3. Lifecycle hooks — call the hooks API at session events:

    • POST /api/hooks/session-start at session start
    • POST /api/hooks/pre-compaction before compaction
    • POST /api/hooks/compaction-complete after compaction
  4. Check daemon health — always verify GET /health returns 200 before making other calls.

See API.md for full endpoint documentation and HOOKS.md for hook integration details.


Working-Memory Fidelity Matrix

All harnesses target the same model:

  • one agent
  • many sessions / branches
  • one shared MEMORY.md head
  • structured retrieval first
  • transcripts as fallback / deep history
  • compaction artifacts feeding the same temporal DAG

Where they differ is lifecycle fidelity:

Harnesssession-startprompt-submitpre-compactionpost-compactionsession-endNotes
OpenCode pluginyesyesyesyesyesReference full-fidelity path
OpenClaw pluginyesyesyesyesyesFlagship path; post-compaction may read summary back from sessionFile when the hook only exposes metadata
Claude CodeyesyesyesnoyesGood continuity, degraded after-compaction fidelity
CodexyesyesnonoyesSolid baseline, degraded compaction fidelity
OpenClaw legacy hooksmanual /contextnonononoCompatibility-only, not full parity

The docs should be read literally. If a hook surface is absent here, that mode is degraded rather than silently assumed.


Harness Status

Check which harnesses are configured:

signet status

Or via API:

curl http://localhost:3850/api/harnesses

Or in the dashboard under the Harnesses section.