kyleandClaude Opus 5.5
67ddda514b
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
25 lines
1.1 KiB
Markdown
25 lines
1.1 KiB
Markdown
## honcho-key-refused
|
|
|
|
**What you see.** `memoryd` logs one line when Honcho refuses a workspace's key, then this entry:
|
|
|
|
```text
|
|
memoryd: Honcho refused the key of workspace boxmaker0-trusted (HTTP 401); nothing more is sent to it until memoryd restarts; see docs/runbook.md#honcho-key-refused
|
|
```
|
|
|
|
**Why.** Each workspace is sent to with its own key, `[secrets.honcho_trusted]`,
|
|
`honcho_untrusted` or `honcho_fleet` (M5c spec, section 10), or none. A 401 or 403 means the key
|
|
is wrong, expired, or missing where Honcho now wants one. Trying again would be refused again, so
|
|
`memoryd` stops sending to that workspace until it restarts; its turns stay waiting in
|
|
`memory/honcho.jsonl`, and the other workspaces go on. The key is never printed.
|
|
|
|
**Confirm.** Which workspace is named, and where its key comes from:
|
|
|
|
```sh
|
|
grep -n -A2 '^\[secrets\.honcho_' /etc/boxmaker/memoryd.toml
|
|
```
|
|
|
|
**Fix.** Put the right key where `[secrets.<name>]` points (see `secret-unavailable` for the
|
|
sources), or remove the table if the workspace needs no key, then restart `memoryd`.
|
|
|
|
**Check.** After the restart the waiting turns are sent, and no line names this entry.
|