@honcho-ai/dsh-honcho

Configuration

Everything behavioral lives in ~/.honcho/config.json under hosts.dsh — the same file claude-honcho, codex-honcho, and the other integrations read. Root holds identity and connection; the host block holds behavior.

{
  "peerName": "your-name",
  "workspace": "honcho",
  "baseUrl": "https://api.honcho.dev", // bare host or …/v3 both fine
  "timeoutMs": 30000,
  "auth": { "apiKey": "${HONCHO_API_KEY}" },
  "enabled": true, // global kill switch
  // sessions may also sit here as a fallback; the host block wins

  "hosts": {
    "dsh": {
      "workspace": "dsh",
      "aiPeer": "dsh", // defaults to the host name
      "observationMode": "unified", // unified | directional
      "sessionStrategy": "per-directory", // see Sessions below
      "sessionPeerPrefix": true, // session names are 
-
      "sessions": { "/path/to/repo": "pinned-session-name" }, // pin a session
      "injection": {
        "sessionStart": ["directives", "summary", "peerCard"], // + representation
        "perTurn": ["userContext", "dialectic"], // userContext = representation + card
        "tools": true,
        "searchTopK": 10,
        "searchMaxDistance": 0.6,
        "maxConclusions": 15, // how many conclusions Honcho RETURNS
        "maxRenderedConclusions": 4, // how many survive filtering into the prompt
        "contextTokens": 1500,
        "cadence": { "dialectic": 5, "ttlSeconds": 300 },
        "dialectic": {
          "reasoning": "low", // minimal | low | medium | high | max
          "maxChars": 600,
        },
      },
      "capture": {
        "saveMessages": true,
        "saveToolUse": false, // one-line summaries of tool activity
        "writeFrequency": "async", // async | sync
        "noisePatterns": [], // additive to the built-in secret patterns
      },
      "messageUpload": {
        "maxUserTokens": 6000,
        "maxAssistantTokens": 6000,
      },
      },
    },
  },
}

Injection components

The two menus differ in cadence, not in what they can carry.

injection.sessionStart is injected once when a session opens: directives (guidance on using memory), summary, peerCard, representation.

injection.perTurn refreshes as you work:

• userContext — a fresh, prompt-scoped peer context blob: representation + peer card, retrieved using your current message as the search query so recall is associative rather than merely recent. It is a bundle, so it supplies both regardless of what sessionStart names. To get one without the other, name it in sessionStart and set perTurn: [] — at the cost of per-turn refresh.
• dialectic — a reasoned answer about you, run every cadence.dialectic turns and shaped by injection.dialectic. Nothing waits on it after the first turn, so a late answer reaches the next one.

Components the canonical schema names but this plugin does not implement — briefing, assistantContext, sessionContext — are reported at startup rather than silently dropped, as are schema keys it does not act on (showContents, statusline, globalOverride, granular observation, multiUser) and any key renamed since an earlier version. Nothing here is accepted and quietly ignored.

The plugin's own cordis.yml config carries plumbing only — configPath, apiKeyRef, host, enabled. Set host to run a credential-isolated profile ("dsh_work") against the same install.

Sharing memory with other integrations

Each integration defaults to its own Honcho workspace — dsh here, claude_code for claude-honcho — and a workspace is the isolation boundary, so by default they do not see each other's memory. Point them at the same workspace to merge them:

"hosts": {
  "dsh":         { "workspace": "shared" },
  "claude_code": { "workspace": "shared" }
}

Keep peerName identical across them too, since conclusions are stored per peer.

Sessions

Default: one long-lived session per project directory, named -, matching claude-honcho. Pin a different name for any path with the root sessions map — an override always wins.

sessionStrategy	Session name	Notes
per-directory (default)	`
-`	Stable across restarts and branches
per-repo	`
-`	Same memory from any subdirectory
git-branch	`
--
`	Falls back to per-directory outside a repo or on a detached HEAD
per-session	`
-chat-`	A clean slate every restart
global	`
`	One memory for everything

Prefer the wider scopes. Honcho's guidance is not to scope sessions too thin: the background Deriver needs a single session to accumulate enough material before it can reason well. git-branch splits a project's memory per branch, and per-session discards it on every restart.