Sage

From source (Go 1.26.9+):

git clone https://github.com/l33tdawg/sage.git && cd sage
go build -o sage-gui ./cmd/sage-gui/
./sage-gui setup    # Pick your AI, get MCP config
./sage-gui serve    # SAGE + Dashboard on :8080

Docker

docker pull ghcr.io/l33tdawg/sage:latest
docker run -d --name sage \
  -p 8080:8080 \
  -v ~/.sage:/root/.sage \
  ghcr.io/l33tdawg/sage:latest

Pin a specific version with ghcr.io/l33tdawg/sage:11.23.24.

The SAGE server stays in that container. To give a local MCP client a stdio bridge, start a second process inside the same running container:

docker exec -i \
  -e SAGE_PROVIDER=claude-code \
  -e SAGE_PROJECT=my-project \
  -e SAGE_IDENTITY_PATH=/root/.sage/agents/claude-code-my-project/agent.key \
  sage /usr/local/bin/sage-gui mcp

For the shipped Compose stack, use the service name rather than a generated container name:

docker compose -f docker-compose.sage-gui.yml exec -T \
  -e SAGE_PROVIDER=claude-code \
  -e SAGE_PROJECT=my-project \
  -e SAGE_IDENTITY_PATH=/root/.sage/agents/claude-code-my-project/agent.key \
  sage /usr/local/bin/sage-gui mcp

If an MCP client launches this through a wrapper, point its stdio configuration at the wrapper's absolute path. Pass SAGE_PROVIDER, SAGE_PROJECT, and SAGE_IDENTITY_PATH through docker exec -e/docker compose exec -e; setting them only on the host-side Docker command does not place them in the container. Keep the whole SAGE data root mounted at /root/.sage, including agent keys and the ledger. Do not start a separate docker run ... mcp container: its localhost:8080 is isolated from the running SAGE server.

HTTP MCP is also available at /v1/mcp/sse and /v1/mcp/streamable, but both require a bearer token or OAuth. Bare http://localhost:8080 is the REST base, not an unauthenticated MCP endpoint.

Upgrading from an older version?

Upgrading an existing node — including the v10.x → v11 jump — is docs/UPGRADING.md. In the desktop app, accept the update: SAGE verifies canonical upgrade compatibility, captures a full recovery snapshot, installs, and restarts automatically. Headless and quorum operators have separate technical procedures in the guide. Your chain advances in place; a personal node climbs the consensus fork ladder by itself. Read the guide before a multi-admin chain crosses app-v23 — that activation re-derives administrator authority.

If you installed SAGE before v5.0 and your AI isn't doing turn-by-turn memory updates, re-run the installer in your project directory:

cd /path/to/your/project
sage-gui mcp install

This installs Claude Code hooks that prompt the memory lifecycle (boot, turn, reflect) — even if your .mcp.json is already configured. Restart your Claude Code session after running this.

What's New in v11.23.24

Find agents across connected SAGEs in one call. sage_find_agent(name="...") searches this SAGE and caller-authorized contacts on connected SAGEs together by default. Exact name matches rank first in one bounded list. Local matches no longer hide remote matches, and same-named agents keep distinct exact addresses so you can choose the intended recipient.

Use scope="local" to search only this SAGE, or peer_chain to select one connected SAGE. If federated discovery cannot be verified, local matches remain available with an explicit incomplete flag. Cached contacts retain their caller-specific authorization checks, and each continuation still reads one bounded peer page.

MCP descriptions and message guidance now point to the combined lookup. After upgrading, re-list tools or reconnect clients with a cached catalog to load the new parameter and guidance. App-v28 remains active and no chain migration is required.

Container: ghcr.io/l33tdawg/sage:11.23.24. SDK 11.23.24.

What's New in v11.23.23

Close reviewed notices without replying. sage_message_close(message_id, reason) records an explicit “closed without reply” outcome for informational or withdrawn messages. Closing retains history and clears pending and unfinished inbox reminders across sessions and restarts. Exact-recipient pending messages need no claim; existing claims remain protected by their current session.

The close reason stays in recipient history and uses the content vault when enabled. Closures create no reply, read receipt, or sender reply activity. Inbound federated closure is local to the receiving SAGE. REST and both Python clients expose the same action, and startup nudges explain when to use it.

App-v28 remains active and no chain migration is required. Clients with a cached tool catalog re-list or reconnect to discover the new action.

Container: ghcr.io/l33tdawg/sage:11.23.23. SDK 11.23.23.

What's New in v11.23.22

Choose which agents a peer can find. Federation visibility uses the complete eligible roster instead of general registry entries that could make a partial selection fail. Search by name, provider, or ID, filter Visible/Hidden, and change an individual agent or only the agents matching your filters.

Review choices in one place. Compact rows, Save/Discard, and inline refresh controls keep visibility edits together. Filtered rows stay in place until saving, preserving keyboard focus. The peer's contacts have their own read-only view, while optional memory sharing and access settings are collapsed separately. Agents whose security policy blocks messages remain marked Not accepting.

Individual and filtered choices stay an exact selection, even when all current agents are selected. Show all agents explicitly includes future eligible agents. Visibility grants discovery only; memory access and message delivery keep their existing authorization checks.

App-v28 remains active and no chain migration is required.

Container: ghcr.io/l33tdawg/sage:11.23.22. SDK 11.23.22.

What's New in v11.23.21

Reliable inbox reply catch-up. The inbox now returns an explicit reply_watermark_candidate to save after processing the complete reply range. Its safety flags describe that inbox response and stay fixed while you page. For a truncated reply page, continue until sage_message_replies returns page_truncated=false, then use the candidate from the original inbox response as the next reply_since. An already complete inbox page needs no pager call. This replaces guidance that could send clients through the retained archive repeatedly.

Paging keeps its bounds. Each continuation supplies the next cursor with the same inclusive since and page limit. If the retained-reply pointer has no valid head, a returned reply page can still supply a candidate; a response with no valid candidate tells the client to omit reply_since on its next poll. Replies at the inclusive boundary remain deduplicated by message ID.

Clients carrying a tool catalog from before inbox v3 must re-list tools or reconnect to discover the existing sage_message_claim and sage_task_notice_ack actions. The server already advertises those tools and sends its tool-list change notification during runtime handoff.

App-v28 remains active and no chain migration is required.

Container: ghcr.io/l33tdawg/sage:11.23.21. SDK 11.23.21.

What's New in v11.23.20

Reading the inbox leaves work pending. sage_inbox now inspects messages and task notices without claiming messages, marking notices read, or creating a reply obligation. Agents accept one authorized message with sage_message_claim(message_id) and acknowledge one reviewed task notice with sage_task_notice_ack(notification_id). Message and task-notice pages advance independently, so a busy message inbox cannot hide task notices.

Agent integrations use the explicit acceptance contract. The old sage_messages_receive MCP tool is removed. Hooks, startup guidance, the Claude channel and the Python SDK use passive inspection; clients must explicitly claim a message before replying. Session ownership, signed federated receipts and recovery of existing claims remain enforced. Reconnect MCP clients after updating so they discover the 36-tool inventory.

Source builds and release builders move to Go 1.26.9, and both Go modules use golang.org/x/net v0.60.0 for the patched standard-library and HTTP/2 dependencies.

App-v28 remains active and no chain migration is required.

Container: ghcr.io/l33tdawg/sage:11.23.20. SDK 11.23.20.

What's New in v11.23.18

SQLite dependency maintenance. The SQLite driver moves to 1.60.1 with its matching libc dependency. This includes WAL shared-memory read-fault handling that returns an I/O error instead of crashing, plus faster argument binding for statements with many parameters. The embedded SQLite engine remains 3.53.4; Go tooling dependencies are also refreshed.

Reranker allocation checks. The reranker keeps its existing limit of 1,000 results. Its result slice now grows only within the capped selection loop, with no input-sized preallocation. Regression tests cover extreme limits, empty and oversized candidate pools, upstream failures and malformed scores.

The optional LoCoMo and LongMemEval benchmark environments now pin datasets==5.0.1, addressing GHSA-379c-qx7v-6h59 / CVE-2026-66007. Browser fixture tests use Playwright 1.63.0.

No consensus execution change, app-version change or chain migration; app-v28 stays active. The experimental, default-off local judge remains pinned to v16, with its runtime, thresholds and published qualification limits unchanged.

Container: ghcr.io/l33tdawg/sage:11.23.18. SDK 11.23.18.

What's New in v11.23.17

The optional local judge is now pinned to v16. On the disclosed frozen 40-item synthetic regression set, the attributed tank-warning example moves from rejection to operator review. All 18 genuine examples avoid rejection: 16 pass and two hold. All 22 negative examples still reject. These results were independently measured on Linux/arm64 with Ollama v0.31.1; they do not establish fresh-holdout accuracy or qualify production installation on every platform.

Select SAGE_LOCAL_JUDGE_MODEL=sage-memory-judge:v16 to use the new pin. The memory gate remains experimental and off by default; upgrading does not rewrite an explicit v15 setting. The download uses an immutable Hugging Face revision with separate SHA-256 pins for the downloaded GGUF and Ollama's registered blob. Thresholds, serving template and runtime are unchanged. See the memory-gate guide and v16 regression results. Thanks to @ihubanov for the update.

No consensus execution change, app-version change or chain migration; app-v28 stays active.

Container: ghcr.io/l33tdawg/sage:11.23.17. SDK 11.23.17.

What's New in v11.23.16

Task creation starts at 0.90 across MCP. When confidence is omitted, sage_remember(type="task") now matches sage_task; other memory types keep their 0.80 default. Corrections resolve the inherited memory type before choosing the default. Explicit scores, including 0 and 0.80, are preserved; malformed, non-finite and out-of-range scores are rejected. The tool schema describes the conditional defaults without inserting a fixed value that could override correction inheritance.

Submission receipts report the score that was signed. submitted_confidence appears on submitted sage_remember writes, including corrections and indeterminate outcomes, and on sage_task creation, replay and committed-but-unconfirmed receipts. It describes the request, not a later stored or query-time score. Skipped or rejected pre-validation and task-status updates do not report a submitted score.

Existing memory scores and task idempotency checks remain intact. There is no consensus execution change, app-version change or chain migration; app-v28 stays active and the qualified v15 local judge pin is unchanged.

Container: ghcr.io/l33tdawg/sage:11.23.16. SDK 11.23.16.

What's New in v11.23.15

MCP stdio bridges exit when their client process dies. Inherited pipes can keep a bridge's input open after its client has gone. SAGE now watches the original parent process, cancels its tools and subscriptions on confirmed parent exit, and bounds cleanup even when input or output is blocked. An idle client keeps its bridge.

Correction lineage resolves by content hash in CEREBRUM. The graph and related-memory view find the parent of a correction through bounded metadata lookups on SQLite and PostgreSQL. Legacy exact-ID pointers still work; ambiguous hashes and hidden parents do not expose a lineage edge or memory body.

A malformed reranker response preserves the original recall results. Missing, duplicate or invalid candidate indices and non-finite scores now discard the reranking response as a whole, keeping the existing reciprocal-rank-fusion ordering. The optional reranker remains off by default; its guidance now asks users to compare relevance and latency on their own queries.

Federation and message failures explain the next step. Local storage and target-resolution failures, plus failed requests to known peers, include bounded diagnostics and remedies. Route diagnostics report only attempted candidates and omit credentials, payloads and peer response bodies. Messaging controls also explain that blocking delivery does not hide an agent from discovery.

The release removes unused memory-transition helpers, expands bounded CI coverage, and documents reproducible retrieval benchmarks and the limits of the public research artifacts. No consensus execution change, app-version change or chain migration; app-v28 remains active. The local judge model stays pinned to the qualified v15 artifact.

Container: ghcr.io/l33tdawg/sage:11.23.15. SDK 11.23.15.

What's New in v11.23.14

MCP tool calls stay responsive while another tool waits on HTTP. Stdio now runs up to 16 tool requests concurrently and reads cancellation notifications immediately. A slow history read can no longer hold later independent tools or the tool registry behind it. Cancellation stops the matching request context; an indeterminate write still requires its normal reconciliation.

AMID restores unresolved signer fences before it starts serving. A private, node-local SQLite ledger preserves identity-only submission intents across process exits. Startup refuses an unreadable or malformed ledger, and a restored fence settles only on chain-proven fate. Disabling the REST validator key also removes the inherited key from ordinary signing paths. A proven fence finishes its durable cleanup before reopening the signer, so a fast next submission cannot lose its new recovery record to the prior cleanup.

Block sync rounds quorum-blocking power up correctly. A validator with power 1 out of 4 no longer leaves block sync early. Actual quorum-blocking power keeps its existing behavior.

An optional local judge checks lasting knowledge and its submitted evidence. Set SAGE_LOCAL_JUDGE_MODEL=sage-memory-judge:v15 to use SAGE's verified local model through its managed Ollama runtime. It remains experimental and off by default. Judge traffic is restricted to loopback, cloud aliases and mismatched model blobs are refused, and an unavailable judge holds proposals for operator review. Public seed-set qualification on SAGE's pinned runtime passed with external networking blocked; support precision was 97% with one accepted trap, and lasting precision was 100%. See the memory-gate guide and runtime qualification report for configuration and limits. Thanks to @ihubanov for the contribution.

No consensus execution change, app-version change or chain migration.

Container: ghcr.io/l33tdawg/sage:11.23.14. SDK 11.23.14.

What's New in v11.23.13

REST submissions keep their acknowledgment through the full write budget. A memory could commit after the server's response deadline had expired, leaving the caller with a connection error instead of the result. The deadline now accounts for embedding retries, the bounded nonce-lease wait and the consensus commit wait, with time for the response. The default is 285.75 seconds and the combined budget is capped at ten minutes; larger custom settings can still outlast that cap.

Vault recovery verifies the key before replacing vault.key. An invalid recovery key is refused before it can overwrite the existing vault key file.

This patch retains the memory gate shipped in v11.23.11. The unreleased evidence checks, managed local judge and model work are deferred. There is no consensus execution change, app-version change or chain migration. The cancelled v11.23.12 tag remains unchanged.

Container: ghcr.io/l33tdawg/sage:11.23.13. SDK 11.23.13.

What's New in v11.23.11

An optional memory-quality gate can hold uncertain memories for review. Set SAGE_HUNCH_URL to enable a background judge for proposed memories, with domain include/exempt settings controlling which memory text reaches the service. Built-in checks still run on every vote, and Settings → Memory gate lets the operator accept or reject held memories. The gate is off by default, supports SQLite stores, and does not change consensus or recall. See the memory-gate guide for configuration and limits. Thanks to @ihubanov for the contribution.

A provably stale memory vote can release its signer fence. When a vote's target has already committed, a stale-vote mempool filter can reject every retry before it reaches an indexed block result. SAGE now recognizes a narrow, versioned refusal for complete canonical memories submitted after app-v25 activation. The resolver binds that refusal to the exact signed vote and rechecks the transaction index before reporting its outcome. Ordinary CheckTx 13 errors and historical or incomplete targets keep the fence held.

CLI help is inert. Asking for serve --help, setup --help, or mcp --help returns usage before command dispatch, configuration, or instance locking, without creating home or project files.

Inbound federated messages wake their exact local recipient. Wake allocation commits atomically with message admission and transport deduplication. Duplicate or rolled-back deliveries cannot create extra wakes, and startup catches up existing unfinished inbound work.

No consensus execution change, transaction-type change, upgrade height, or chain reset. AMID operators must preserve unresolved transaction identity and signed bytes during maintenance: cmd/amid does not wire the durable-intent restore hooks used by sage-gui, so restarting it is not a fence-recovery proof.

Container: ghcr.io/l33tdawg/sage:11.23.11. SDK 11.23.11.

What's New in v11.23.10

A held signing key can no longer park the node's whole write path. A signer fence refuses every write from its key while it waits for proof of an earlier submission's fate, and that wait was bounded only by the caller's context — which the submit path passed as context.Background(), a context that never cancels and carries no deadline. The one goroutine holding the node's single signing lease sat there for as long as the fence stood — one observed node carried handlers parked 122–768 minutes — and every later writer for that key queued behind it on the same size-one lease, including the automatic reconciler whose job is to settle the fence and release it, so the hold could not clear itself. Reads stayed fast and denied writes still failed fast, which is why the incident reached the operator as writes time out, no error. WithNonceLease now derives a bounded wait (90 s) when the caller supplies no deadline, so a held fence fails retryable instead of parking, the lease is released, and the reconciler is no longer starved by the fence it exists to lift. A caller that supplies its own shorter deadline keeps it.

Background work the embedded web handler starts can no longer outlive the store it writes to. That handler started goroutines with no lifecycle owner, and unowned work that outlived its caller's store touched a closed database and panicked the process — first seen inside this repository's own suite, where one test's projection audit tore down another test's store. Unowned background work is counted now, and a caller that owns the stores drains it with WaitBackground before closing them.

Build and tooling. Local make builds pin to the host architecture instead of assuming amd64, and a Codex session started in a checkout inherits that checkout's Codex pin from .codex/config.toml — the counterpart of the existing .mcp.json Claude Code pin, so one workspace can carry both providers' pins. Dependency groups were refreshed.

No consensus change, no transaction-type change, no upgrade height, and no chain reset.

Container: ghcr.io/l33tdawg/sage:11.23.10. SDK 11.23.10.

What's New in v11.23.9

CEREBRUM now shows a held signing key. A signer fence refuses every write from its key and every coordinated restart while it waits for proof of an earlier submission's fate, and until this release the dashboard said nothing about it — the field report that produced the fence workstream read from the outside as reads are fine, writes time out, no error. System Status gains a row that appears only while a key is held: how many keys and how long, the node's own explanation of why the hold is deliberate, and one line per fence naming its resolution. reconciling means the identical bytes are still being re-submitted and it clears itself; waiting on proof means the signed bytes did not survive the process, so the chain or an operator has to settle it. Each line carries the nonce, how long the key has been held, the attempt count and the last recorded detail.

A hold that ends stays visible. The row above disappears with the fence, which left no way to tell it lifted while I was reading from it never happened. The last resolution is now kept and rendered — committed, rejected, spent, or resolved without a proof — so a fence that cleared itself is still on screen afterwards.

Two details that make the numbers trustworthy. The nonce crosses the wire as a string: SAGE nonces are nanosecond allocations that exceed JavaScript's safe integer range, and as a JSON number it reached the browser silently rounded, in the one place the operator compares it against the chain. And the panel never suggests restarting to clear a hold — a restart discards the fence and loses the transaction it protects, which is the failure the whole mechanism exists to prevent.

No consensus change, no transaction-type change, no upgrade height, and no chain reset.

Container: ghcr.io/l33tdawg/sage:11.23.9. SDK 11.23.9.

What's New in v11.23.8

A node stops manufacturing signer fences on an ordinary quit. Since the fence landed, every coordinated restart has drained signing before it committed, so its teardown could not sever a broadcast mid-flight. A plain signal or a serve error had no such drain: the HTTP force-close could catch a submission, raise an indeterminate outcome, write a durable fence record, and cost that payload at the next start — the fence can only lift on a proof, and a live one whose re-submission is refused by anything other than the nonce gate has no proof to reach. The ordinary exit now drains the same way the restart does: signing is quiesced, in-flight submissions get a bounded five-second window to finish, and only then do the listeners close. Signing is deliberately not resumed, because the process is leaving; an operator-ordered exit is never vetoed by the drain; and a submission that cannot finish in the window fails closed onto the durable record and the restored fence.

sage-gui fence abandon works on a node that keeps a peer. The credential-free operator exit added in 11.23.6 applies the same evidence gate as the daemon's abandon route, including its second acknowledgement for connected peers — a peer is a route the abandoned bytes could still take back into this node's mempool. The CLI had no way to carry that acknowledgement, so on a federated desktop node or a validator with a persistent peer it could only ever refuse and point at a field it had no way to set. --peer-redelivery-acknowledged now carries it, fence list names the requirement when peers are connected, and every unproven record states the restart step: a running daemon keeps holding the key until it restarts, and the durable record is what the next boot restores from.

No consensus change, no transaction-type change, no upgrade height, and no chain reset.

Container: ghcr.io/l33tdawg/sage:11.23.8. SDK 11.23.8.

What's New in v11.23.7

A node that has activated app-v28 can install its own updates again. The signed update flow takes a pre-upgrade recovery snapshot and proves it before it touches the installed app: the manifest carries the AppHash the running chain committed, and the proof restores the Badger backup and re-derives that digest from the restored bytes. Since app-v28 the committed AppHash is the public-memory composite commitment — the app-v13 digest of the state WITHOUT the public-memory index nodes, composed with the sparse index root — and the proof only knew the three earlier eras. Every app-v28 node therefore refused its own recovery snapshot, and the field report was exactly this shape: Failed to install signed app update: verify pre-upgrade snapshot: ... AppHash mismatch under every hash rule (legacy/app-v12/app-v13), with the update stuck on the snapshot step and no way forward from inside the app.

What now happens: the composite joins the candidate set, read through the same internal/store implementation the commit path uses instead of a second copy of the rule — the state-sync provider verification path already went stale exactly that way once, refusing every v28 provider while every pre-v28 chain stayed green. A pre-v28 state carries no public-memory commitment, so the composite is reported as not-applicable there and the three older candidates decide alone. The mismatch message now names the rules that were actually tried.

If you are reading this from an app-v28 node on 11.23.6 or earlier, read this part. The gate that just failed runs inside the binary you have installed, so that binary cannot install this release either — and the same gate vetoes a version-changing restart. Installing 11.23.7 once by hand is the path out: quit SAGE, drag SAGE.app from the DMG into /Applications, relaunch. Every update after that one works from inside the app again.

No consensus change, no transaction-type change, no upgrade height, and no chain reset.

Container: ghcr.io/l33tdawg/sage:11.23.7. SDK 11.23.7.

What's New in v11.23.6

A fence on a quiet chain settles itself, and the operator has a way in when it cannot. SAGE chains are idle by design: since app-v12 every node sets create_empty_blocks=false, so a block is minted exactly when a signed transaction enters the mempool and the chain sits still otherwise. A fence restored from durable intent refuses to sign, and its signed bytes did not survive the process — so on a chain that was already quiet when the fence was raised, the fence was holding the only thing that could produce the proof it was waiting for. No transaction meant no block; no block meant no committed hash and no advanced committed nonce. The key was held forever, every write and every cleanup on that node was refused, and the field report was exactly this shape on a single-validator personal node.

What now happens: when the node is caught up, has no peer and has seen none while this fence was held, holds no mempool copy of the transaction, sees no committed fate for its hash and holds an unspent allocation, the node settles the fence itself, records fence_abandoned and the full evidence, reserves the abandoned allocation so the next transaction cannot reuse it, and lets the next write mint the block that wakes the chain. TWO EVIDENCE SETS REACH THAT DECISION and the log names which one did: mode=automatic_unprovable is the original startup resolution, and mode=automatic_quiescent is the rule added here for a chain that has minted nothing since the fence was raised — the first now succeeds where it previously could not, because the reader defects below were what stopped it reaching its gates.

What still holds the fence: a tip that has minted since the fence was raised, any connected peer, a peer seen under this fence, a mempool that holds the transaction — that is a chain with something to mint and the fence is what stops it, so it stays an operator decision — a node still catching up, a tip that cannot be read, a live fence whose exact bytes still exist, and any record without a nonce.

Every outcome of the automatic route is now visible. Its refusal reason reaches the fence's last_detail, and so does a FAULT — the fault branch was previously dropped silently, which made a node whose self-heal could not read its own evidence look identical to one that was merely waiting. A field report read that as "the automatic route never ran".

The operator has a real entry. sage-gui fence list prints every recorded fence with its signer, transaction, nonce and age, and says whether the chain can already settle it. sage-gui fence abandon --signer <key> --reason <why> --acknowledge-payload-loss retires one record from the node host through the same evidence gate the daemon's operator route applies — no credential, no browser, and it says plainly that a running daemon keeps its in-process fence until it restarts. This closes a field gap: the dashboard had no control for this action, and an HTTP MCP bearer token is not accepted by the operator gate, so the only local entry was a browser console.

No consensus change, no transaction-type change, no upgrade height, and no chain reset.

Container: ghcr.io/l33tdawg/sage:11.23.6. SDK 11.23.6.

What's New in v11.23.4

A fence on a quiet chain settles itself. SAGE chains are idle by design: since app-v12 every node sets create_empty_blocks=false, so a block is minted exactly when a signed transaction enters the mempool and the chain sits still otherwise. A fence restored from durable intent refuses to sign, and its signed bytes did not survive the process — so on a chain that was already quiet when the fence was raised, the fence was holding the only thing that could produce the proof it was waiting for. No transaction meant no block; no block meant no committed hash and no advanced committed nonce. The key was held forever, every write and every cleanup on that node was refused, and on a single-validator personal node the hold had no exit at all — the operator route needed a credential the operator could not present.

What now happens: when the node is caught up, has no peer and has seen none while this fence was held, holds no mempool copy of the transaction, sees no committed fate for its hash, holds an unspent allocation, and the chain's tip was minted before this fence was raised, the node settles the fence itself, records the decision as fence_abandoned with mode=automatic_quiescent and the full evidence (including the tip height and time), reserves the abandoned allocation so the next transaction cannot reuse it, and lets the next write mint the block that wakes the chain.

What still holds the fence: a tip that has minted since the fence was raised (that chain can still speak to these bytes), any connected peer, a peer seen under this fence, a mempool that holds the transaction — that is a chain with something to mint and the fence is what stops it, so it stays an operator decision — a node still catching up, a tip that cannot be read, a live fence whose exact bytes still exist, and any record without a nonce.

No consensus change, no transaction-type change, no upgrade height, and no chain reset.

Container: ghcr.io/l33tdawg/sage:11.23.4. SDK 11.23.4.

What's New in v11.23.3

The fence fixes now reach the nodes that keep a peer. v11.23.3 could prove a restored fence's fate and settle the shape no proof can reach — but only on a node that had never seen a peer since it started, and its operator abandon route refused outright whenever any peer was connected. A federated desktop node, or any validator with a persistent peer, therefore sat behind a fence that no proof could settle with both recovery routes closed: writes refused, updates vetoed, indefinitely. That is the report this release answers.

The peer observation is anchored to the fence, not to the process. A sighting from an earlier outage — a peer that connected while the node was starting, a peer gone for hours — can no longer switch self-healing off for every fence raised afterwards. What still holds is the honest rule: the automatic route refuses while a peer is connected, or was seen while this fence was held, because a peer is how a transaction gets delivered back.

The operator abandon route now says what it needs. It reads the live peer count, still records it with the decision, and requires a second, explicit acknowledgement — peer_redelivery_acknowledged — when peers are connected. The operator can see the topology (whether that peer was running when the submission went out, whether it ever held the bytes); the node cannot, so it states the route it cannot rule out instead of refusing by construction.

The health surface says HOW a fence ends. Each held fence now reports a resolution class: reconciling means the node still holds the exact signed bytes and is re-submitting them until consensus answers, so it clears itself; proof_or_operator means the fence was restored from durable intent and its signed bytes did not survive, so only a chain-read proof or an explicit operator abandon will lift it. The block's explanation is rendered from that distinction instead of promising self-healing for every fence, and the automatic route's own refusal reason (still catching up / peers connected / a peer seen under this fence) is recorded with the fence rather than computed and dropped.

Agents can read it directly. The MCP surface gains a read-only sage_node_health tool (the 35th): it forwards the node's signer_fences block and renders the guidance from the resolution class, and says "not knowable from here" rather than guessing on a node too old to report one. A write refused with 503 Signing key temporarily held can now be diagnosed by the agent that hit it, without an operator shell.

No consensus change, no transaction-type change, no upgrade height, and no chain reset: this decides when a key may sign again, not what the chain accepts.

Container: ghcr.io/l33tdawg/sage:11.23.3. SDK 11.23.3.

What's New in v11.23.3

A held signing key can no longer strand a node, and a write that hits one says so. The signer fence refuses to let a key sign anything new while an earlier transaction's fate is unproven — that part is deliberate and unchanged. What was wrong was everything around a fence that got restored after a restart: its signed bytes are gone, so re-submission cannot prove anything, and the node had no other way to settle it. It held the key, refused every coordinated restart (which is every in-app update), and the only exits were an operator POST that needed a proof the chain did not have, or hand-editing the database. Users hit it as an upgrade that could not be installed and, on the nodes that did restart, as writes that timed out with no error while reads stayed fine.

A restored fence now proves what it can, and settles what it cannot. On the first boot of this release the node re-reads the chain for the two proofs it accepts — the recorded transaction hash found in a committed block, or the signer's committed nonce having reached the fenced allocation — on the same retry schedule the live reconciler uses, and lifts the fence the moment either exists. For the shape no proof can ever settle (the transaction never committed, and the bytes died with the process that sent them) the node resolves the fence itself once the evidence is unambiguous: it is caught up, it has seen no peer this run, nothing is queued in its mempool, the recorded hash is in no block, and the allocation is unspent. That decision is recorded as a fence_abandoned event with mode=automatic_unprovable and the full evidence, and the abandoned nonce is reserved so the next transaction cannot reuse it. A node that has talked to a peer keeps its fence — there the transaction can still come back, and only a proof or an operator may lift it.

The restart veto now asks the right question. It used to refuse any coordinated restart while a fence was held, on the reasoning that a restart discards the only record of a possibly in-flight transaction. Since durable intent landed, that record is on disk and is re-raised at the next start, so the veto now refuses only when it cannot confirm the record survives (an unwired, unreadable or missing intent row — it fails closed). Refusing blanket-wide was itself the bug: a fenced node would not take the restart that installs the release carrying the fence's own proof reader and recovery.

A fenced write is refused immediately instead of hanging. The lease's fence wait blocks until the caller's deadline, so an agent writing to a fenced node saw a bare timeout. Request-serving paths now check first and answer 503 with Retry-After, naming the transaction the key is held on and stating that nothing was signed or sent.

Already stuck on v11.23.2? Replace the app. A node that is fenced right now refuses the in-app restart that would install this release, so the recovery is the app itself: drag the new SAGE into Applications, replacing the old copy, then quit and reopen it. The first boot of v11.23.3 resolves the fence on the evidence above and writes work again — no terminal, no command to run. The proof route (POST /v1/dashboard/signer-fence/lift) still exists for anyone whose key can be proven, and the operator abandon route remains for fleets that keep their fence because they have peers.

No consensus change, no transaction-type change, no upgrade height, and no chain reset: this decides when a key may sign again, not what the chain accepts.

Container: ghcr.io/l33tdawg/sage:11.23.2. SDK 11.23.2.

What's New in v11.23.2

A chain whose public corpus predates app-v28 can open the fork. The public-memory stage is built by BuildPublicMemoryMigration, which refused to produce a leaf for any PUBLIC=0 record it could not canonically encode — and a real chain carried 53 legacy records whose canonical content hash had been erased by a historical lifecycle transition. Because the stage is prepared outside the consensus transaction, that refusal aborted the activation block on every replay: CometBFT re-entered "replay last block using real app" and the node could not start at all, so upgrade cancel could not help either — it is itself a consensus transaction. Those records are now quarantined out of the committed public set instead of failing the build, exactly as the co-commit tombstone index already treats a record whose decoded hash is not 32 bytes, and a record joins the set in the block that re-anchors its hash.

Narrow by design. Only a record accepted before app-v25 lacks a submission-height marker, and only those could have had their hash erased by a legacy lifecycle transition, so a missing hash on a record born under app-v25 or later is still a hard inconsistency that refuses the build. Nothing about the commitment itself changes: this decides whether an activation succeeds, not what the fork commits.

No transaction-type change, no upgrade height, and no chain reset.

Container: ghcr.io/l33tdawg/sage:11.23.2. SDK 11.23.2.

What's New in v11.23.1

An amid-only fleet can set an agent's enrollment clearance. A validator fleet with no CEREBRUM SPA could not raise an existing agent's clearance: the only producer of TxTypeAgentRoleChange is the dashboard policy route, the legacy PATCH route is retired post-app-v23, and amid served neither. amid now mounts exactly two dashboard routes on its own REST listener — GET /v1/dashboard/network/access and PUT /v1/dashboard/network/access/agents/{id}/policy — with the same handlers and the same operator gate CEREBRUM serves, so the transaction is identical. The caller signs the exact request as the current Root; the node's configured broker key (--cerebrum-root-key-file / SAGE_CEREBRUM_ROOT_KEY_FILE) is that credential, and a node without it answers root_key_unavailable instead of degrading open.

Enrollment clearance is the one the memory-write gate reads. Membership clearance is a different record and never satisfies the gate that compares a submission's classification against the agent's enrollment clearance; this is the surface that writes it, with the role and enrollment revisions the read route exposes.

No transaction-type change, no consensus change, and no chain reset. A patch release inside the 11.23 line: the shipped native shell already admits v11.23 daemons, so no shell range moves.

Container: ghcr.io/l33tdawg/sage:11.23.1. SDK 11.23.1.

What's New in v11.23.0

App-v28 activates. maxSupportedAppVersion moves 27 → 28 and converges with the compiled ceiling, so the gate v11.22.0 shipped dormant becomes an automatic rung: a personal node now advances its own chain across the seam on upgrade with no governance ceremony, the same path every earlier rung took. What activates is the sparse public-memory Merkle commitment over committed PUBLIC=0 records — AppHash-covered through a composite rule that hashes the legacy tree without the index nodes and composes it with the index root — and the co-commit tombstone rule, now enforced by the consensus path behind a content-hash reverse index maintained by every memory write and backfilled at activation.

The state-sync item that blocked it is fixed, and the contract's evidence is complete. A v28 provider used to die on its state-sync serving boot: the verification family recomputed the pre-v28 AppHash rule unconditionally, so the composite root could never match, the process exited with persisted AppHash does not match Badger state, and the caller waited on a Comet RPC that never became ready. The rule is now selected in one function shared by the commit path and the verification path, so the two cannot disagree about which rule is in force. TestAppHashDeterminism_AppV28Activation walks a fresh four-validator devnet app-v2 → app-v28 one rung at a time with byte-identical AppHash at H-1/H/H+1 of every seam; both Consensus Fault Gates pass on this change; and the real-process state-sync gate drives its provider through app-v28 (TARGET_APP_VERSION=28), so a pristine receiver restores from the provider snapshot and both sides report exact app-v28 state with converging AppHash. The gate's receiver pre-publication SIGKILL and provider SIGKILL phases, plus the replay family that pins historical blocks to their original app versions, cover restart and replay equivalence across H.

The native shell rides this release. A minor bump is the release that widens the shipped shell's SSCP compatibility range, which now admits v11.23 daemons — so fixes after this one ship as patch releases under the same shell.

No chain reset and no transaction-type change; historical blocks keep replaying under their original app versions.

Container: ghcr.io/l33tdawg/sage:11.23.0. SDK 11.23.0.

What's New in v11.22.1

App-v28 stays dormant in this release. v11.22.0 shipped the public-memory commitment and the consensus-side co-commit tombstone rule as one compiled gate, with the auto-vote ceiling deliberately held at 27 until its evidence existed. That evidence is nearly complete — the four-validator determinism ladder crosses every seam to app-v28 with byte-identical AppHash, and the upgrade gate drives the whole ladder with auto-votes — but the contract's last item, a promoted node surviving state-sync and restore, currently fails: a v28 node restarted by the real-process state-sync gate comes back, serves, and then stops answering. The ceiling bump ships in the release that turns that green, so app-v27 remains the ceiling here and the deliberate path (propose plus explicit votes) is unchanged.

The Federation page now leads with your connections. Managing a link used to mean scrolling past a status rail, the master switch, a network-name editor, a connectome for every agent, an always-open pairing wizard and only then the connections themselves, and per-agent discovery hid behind a Save button inside an expanded panel. The page opens on Your trusted SAGEs instead. Each connection row states its own discovery posture — all agents visible, N agents visible, or no agents visible — from one bounded read per link, so the row answers without expanding. The connectome and sharing groups move into collapsed Explore agents and Sharing groups sections at the bottom, and the pairing wizard appears only when there are no connections or when Connect a SAGE is used.

Agent visibility is a switch, not a form. Every eligible agent on a connection's roster carries a Visible/Not-visible switch that saves immediately under the connection's revision-bound agreement. The switch works on the full roster, so hidden agents never vanish from the operator's list, and Show all agents / Hide all agents move the whole roster at once. The Save-then-Saved form is gone, and copy-address is demoted to a quiet secondary action on peer cards.

The SDK can set an agent's enrollment clearance. set_agent_access_policy(agent_id, role, profile, clearance, capabilities=0, home_domain=None) writes the atomic app-v23 policy endpoint, and get_access_state() reads the consensus-authoritative snapshot back, so a script verifies the write landed instead of inferring it. This closes a gap that reads as a bug: the memory-write gate compares a submission's classification against the agent's enrollment clearance, not its organization or department membership clearance, so an operator who granted clearance through membership saw every classification ≥ 2 write refused while get_profile() still reported clearance 1.

CEREBRUM's App version panel renders on every node. The panel (chain rung, both ceilings, the Propose button) was nested behind the governance-scope list, so it never rendered on a personal node — scope records only exist once a scope_action commits, and most nodes have none. It now renders on its own, and only the scope cards stay gated.

No consensus change and no chain reset. maxSupportedAppVersion stays 27.

Container: ghcr.io/l33tdawg/sage:11.22.1. SDK 11.22.1.

What's New in v11.22.0

App-v28 ships compiled and dormant, on purpose. Two consensus-visible changes now exist behind one gate. The sparse public-memory Merkle index over committed PUBLIC=0 records becomes AppHash-covered at the activation height, through a composite rule that hashes the legacy tree without the index nodes and composes it with the index root. The co-commit tombstone rule stops being a check at the local REST submission boundary and becomes a rule the consensus path enforces. Neither one is active: maxSupportedAppVersion stays 27, so every node's upgrade auto-voter abstains on v28 and a personal node cannot advance itself into the fork. Activation waits for the evidence the contract names — byte-identical AppHash across the seam on a four-validator devnet, both Consensus Fault Gates, a promoted node surviving state-sync and restore, and replay equivalence — and ships in the release that carries it. An explicitly proposed, quorum-approved plan can still activate it; nothing does so on its own.

View the full README on GitHub