Two things, because the second could not be built on the first. The schema stamp was part of the same execute_batch as the CREATE TABLE IF NOT EXISTS statements, and it wrote unconditionally. Opening an older file therefore added no columns but flipped the version forward anyway; opening a *newer* file stamped it back down and then wrote rows the newer build could not read. Both produced a database whose recorded version was a lie, and every future schema change would have inherited it. Now the version is read before anything is applied, migrations are ordered and forward-only inside one transaction, a newer file is refused with SchemaTooNew rather than downgraded, and a supported version raised without a step to reach it fails at the first open instead of claiming success. Tested by stamping a file at version 99 and asserting both the refusal and that the stamp is left untouched. lumbridge-settings resolves compiled default -> settings.toml -> environment. The environment sits above the file deliberately: decision 0016 calls LUMBRIDGE_CLAUDE_OAUTH=0 "one switch off", and a switch a config file can silently re-enable is not a switch. A pinned value renders disabled and names the variable, rather than accepting an edit that would do nothing. Every field carries a WriteAuthority. Routing all writes through Configure is the obvious design and would hand a layout-only agent the program every future pane launches — the guarantee decision 0006 exists to make. Anything naming a program, path or destination is Human-only, asserted by a test that reads the path rather than trusting the author. Four paths are permanently not settings, with the reason recorded beside each and a test asserting their absence: the usage endpoint URL, the credentials path, the client identity, and the shell program. A configuration file that can redirect where an access token is sent is a credential exfiltration path with a friendly name. Environment access is a trait rather than std::env, because the workspace forbids unsafe, set_var is unsafe in Rust 2024, and the layering rule has to be testable without mutating the process running the test. Verified live with LUMBRIDGE_CLAUDE_OAUTH=0: the account-endpoint row reads off, greyed, "pinned by LUMBRIDGE_CLAUDE_OAUTH". The Advanced page names every file, endpoint and child process Lumbridge touches and states that nothing is sent anywhere else — as a fact, not as a toggle nobody can flip. File loading, comment-preserving writes and editable controls are not in this pass; 0022 records why that order is the honest one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lumbridge
Lumbridge is a fast, local-first workspace and terminal multiplexer for agentic engineers. It will run coding harnesses side by side, preserve their sessions, connect rich agents through ACP, and show trustworthy account and usage context without forcing users into one model vendor.
The first supported desktop platforms are:
- macOS (Apple Silicon first, Intel when CI capacity is available)
- Ubuntu Linux
- Omarchy and compatible Arch Linux systems
Lumbridge is free and open source under Apache-2.0. Releases will be published as installable binaries; building from source will remain supported.
Status
This repository is in architecture and vertical-slice phase. The installable binary is still a scaffold, while the isolated native UI spikes now exercise an interactive 20/60/20 workspace backed by six live comparison surfaces, and the root workspace contains the first bounded local PTY, runtime actor, VT engine, and capability-gated workspace command boundaries. The GPUI slice shows a responsive one-, three-, or five-panel workspace—five on a 3440 px ultrawide— where every panel owns its own context, work surface, and decision shelf. One panel contains a styled actor-owned VT session and five comparison surfaces remain deterministic. Retained-history navigation is wired. The usage footer is a live strip over an append-only ledger with provenance, fed by two real adapters: Codex's documented quota surface and Claude Code's session transcripts. A harness with no adapter renders an explicit gap rather than a zero. We are still validating terminal text selection and mouse input, standalone runtime IPC/durability, ACP integration, and packaging before a large implementation.
Product shape
- A native desktop shell with tabs, panes, workspaces, worktrees, diffs, and an agent-aware footer.
- A Rust session runtime that survives UI restarts and can later run headless.
- ACP-native integrations where available, with supervised PTYs as the universal fallback for any CLI harness.
- First-class harnesses for Claude Code, Codex, DeepSeek Harness, Pi, Hermes, OpenClaw, Goose, Gemini CLI, and OpenCode.
- Subscription login owned by the upstream harness, plus separate BYOK provider profiles for OpenAI, Anthropic, Gemini, Groq, Cerebras, DeepSeek, and more.
- Usage history, burn rate, reset windows, and forecasts with visible data provenance instead of invented precision.
- Optional first-class Buzz channels, messages, agents, and confirmed redacted pane sharing without making Buzz a requirement.
- An optional Lumbridge Harness that can suggest, coordinate, and—with explicit execution capability—manage agents through the same audited command plane as the human UI. Lumbridge remains useful without it.
Start with the product spec, architecture, research map, and captured upstream revisions. The native UI choice is intentionally open; see the measured decision plan.
Scaffold
bacon # continuous check; t tests, c lints, v runs the full gate
cargo xtest # fast isolated tests with nextest
./scripts/ci.sh # format + strict Clippy + tests + doctests
cargo run -p lumbridge
See the testing strategy for fake harnesses, ACP replay, terminal conformance, UI driving, recovery, performance, and packaging tests.
The accepted local/remote boundary is recorded in
decision 0003. The two
native shell candidates live in spikes/, with results tracked in
the UI scorecard.
The signed-protocol and pane-sharing boundary is in
the Buzz integration design.
Brand masters, platform-ready raster exports, and usage rules are in
assets/brand/ and the brand guide.