Notes from the codebase.

May 2026 · Sandbox behavior became visible

Harper now treats sandboxing as a visible command-runner behavior instead of a quiet backend detail. Command output reports the active sandbox profile, backend, and network state before the command result, so it is clear whether a command ran without a sandbox, inside the workspace profile, or inside the networked workspace profile.

The config path is simpler too. The named sandbox_profile values own the common modes, while [exec_policy.sandbox] stays available for explicit path and network overrides. If sandboxing is enabled but Harper cannot find a supported backend, the command fails instead of silently running outside the requested boundary.

May 2026 · Shell

Harper now has a native command surface for Harper state. Instead of treating every operational action as either prose or an operating-system command, the TUI and batch mode can both understand commands such as plan show, session list, history show, config show, auth login, and update check.

The boundary is intentional. This is not a Unix-compatible shell, and it does not try to support pipes, redirects, glob expansion, or job control. Operating-system commands stay explicit behind run ..., which keeps them on Harper's existing approval, sandbox, and audit path. Native commands are for Harper concepts: plans, sessions, history, auth, config, update status, and diagnostics.

The practical win is consistency. The same parser is used from the interactive TUI and from harper-batch, so a workflow can be checked headlessly before it is exercised in the UI. That gives Harper a clearer command model without hiding the underlying actions.

May 2026 · Harper now supports native self-update

Harper can now update itself as a product feature, not only through external package-manager workflows. Direct installs support harper self-update --check to inspect the published release manifest and harper self-update to download and replace the installed binary when a newer version exists.

The important part is trust and scope. Package-managed installs still defer to the package manager, so Homebrew, cargo, and npm users are pointed back to the correct upgrade command instead of having Harper overwrite those installs directly. Direct installs follow a stricter path: the updater checks the manifest, selects the current platform artifact, verifies the published checksum, verifies a detached release signature, and only then replaces the local binary.

The TUI now exposes that same state in a lighter form. The header can show update status, /update and /update check can refresh it on demand, and the Execution Policy screen includes a direct Updates action. The result is not a new packaging story by itself. It is a cleaner operational path for staying current once Harper is already installed.

May 2026 · Shell-first verification is now the default debug path

One of the most practical changes in recent Harper work is not visual. It is the addition of a shell-facing verification path through harper-batch. That matters because the fastest way to debug routing, command normalization, follow-up resolution, and strategy behavior is not to open the TUI first. It is to run the same prompts headlessly and inspect the control path directly.

The useful shift is clarity. Harper can now report the selected strategy, task mode, routed deterministic intent, normalized command, runtime activity, and final assistant reply in one shell-visible flow. That makes prompts such as where is execution strategy used in this repo, run the git status, and run that much easier to validate before spending time on UI-specific issues.

This also sharpened the product split between strategies. deterministic is now easier to verify as a strict grounded tool path. grounded prefers deterministic grounding first for supported repo questions and then allows model synthesis when needed. auto stays tool-assisted, but it no longer has to fail noisily when a deterministic fallback exists. The result is not that Harper became simpler. The result is that it became more inspectable.

April 2026 · Cargo and Bazel validation got tighter

Some of the recent Harper work was not product-facing at all. The repo now has better parity between Cargo and Bazel validation, which matters because changes that compile and test under one path need to fail fast under the other as well.

This is mostly contributor-facing engineering work: aligning default config assumptions with test environments, closing dependency wiring gaps, and making sure the signed-in local workflow behaves the same way in local development and CI.

April 2026 · Signed-in local workflows are now account-scoped

Harper still works without sign-in, but the signed-in path is now a real product mode rather than a thin auth callback. When you sign in, the local TUI session is stored in the OS credential store, the Profile screen in Settings shows the active account, and session refresh can happen automatically when a remote request hits an expired access token.

The more important behavioral change is scope. History, Export, and Statistics now follow the signed-in account instead of mixing account-owned sessions with unrelated local state. That makes the local client behave like a user-aware workspace while preserving unsigned local-only use for people who do not want authentication at all.

April 2026 · Local sign-in now works through Supabase

Harper now has a real local sign-in path instead of only provider API keys. The local server can start a browser-based Supabase login, complete the callback, verify the returned session, and expose the signed-in user through /auth/me. The TUI can also start and poll that same auth flow without depending on browser cookies directly.

This changed more than one route. The final shape includes callback handling, PKCE code exchange, user-scoped session access, and asymmetric JWT verification against Supabase signing keys. That matters because local auth is only useful if the session is actually enforced everywhere the server exposes user data.

April 2026 · Planning became real state

Harper now treats planning as part of the session model instead of something implied in prompt text. Plans persist with the session, show up in the TUI, and can be updated through the tool loop and HTTP chat path. That matters because longer tasks need visible progress, not just a good initial answer.

The product implication is straightforward: once plan state is real, the UI can show what is pending, what is active, and what just changed. It also means future automation can attach tool execution and job status to actual steps instead of relying on the model to narrate everything correctly.

April 2026 · Execution strategy became explicit

Harper now exposes execution strategy directly in the TUI and local config. The point is to make the control path explicit. deterministic prefers strict direct-tool handling for supported intents, grounded prefers deterministic grounding first for routable repo questions and then allows model synthesis when needed, auto stays tool-assisted, and model disables deterministic shortcuts.

This also cleaned up a real failure mode in local-model sessions. Harper now has a shell-verifiable path for repo-grounded prompts and command follow-ups, so weak or unavailable model backends no longer have to break every operational check. When the model backend is unavailable and no deterministic fallback exists, Harper now returns a clear assistant reply instead of surfacing a raw transport error.

April 2026 · AGENTS.md stopped being a flat append

Earlier builds treated AGENTS.md as one static block of prompt text. Harper now resolves applicable files from repo root down to the target path, merges rules with deeper precedence, and keeps both the raw sources and the effective rendered view available to the UI and API.

That changes the system from “some instructions were probably present” to a more inspectable model where the user can see which file supplied which active rule. For code-editing tools, that is a practical improvement, not just a prompt refinement.

April 2026 · The TUI started showing work in progress

One of the bigger gaps in earlier Harper builds was responsiveness during a turn. The assistant could be working, but the interface did not make that state obvious enough. The TUI now carries explicit activity status, live plan updates, command-output panels for shell work, and persistent loop-state feedback for planned tasks.

The goal is not cosmetic animation. The goal is to remove ambiguity: planning, inspecting, waiting for approval, running a command, and returning a final reply are different states, and the interface should show them as different states. The same core flow is also available headlessly through harper-batch for shell-first verification before opening the TUI.

April 2026 · Session state is getting unified across interfaces

Harper has both a TUI and an API, and those surfaces drift if they do not read from the same shape. Recent work moved messages, plans, and effective agent guidance into a shared session-state view so the TUI and HTTP layer stop assembling overlapping payloads in different ways.

This is less visible than a UI change, but it is important architecture. A stable shared state model reduces mismatches between what the API knows, what the TUI renders, and what future clients can depend on.

How to read this page

This blog is intentionally small. It is not meant to be a marketing feed or a dumping ground for every merged patch. Use it to understand direction. Use the changelog for release detail, the API server page for integration work, and the main docs for day-to-day usage.