v0.7.1

Fixed

• Upgrade v10 and v11 hosts from Settings again. Update the web server first, then use Settings → Hosts → Update. An isolated shim welcomes old daemons as their own version and speaks only their existing update contract; chat, workspace operations and old session frames remain disabled. Native busy-host, preflight and restart safeguards are unchanged. Shared installations use the existing restart-only update after the server's files are replaced. An old daemon that already exited needs starting once.

Added

• Maintenance API v1, independent of application Protocol v12. A separate host-token-authenticated connection provides status, session inventory and activity, capabilities and software updates even when application protocols differ. Session traffic uses Protocol v12; future application incompatibility no longer needs to disconnect maintenance. Reverse proxies must forward /api/hosts/maintenance WebSocket upgrades as well as /api/hosts/link.

Upgrade

npm install -g @kahme247/ompweb@0.7.1

Full changelog: v0.7.0...v0.7.1

omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7

v0.7.0

Breaking changes

• ompweb ships its own omp, ompweb-omp; omp no longer needs installing. Every session runs on ompweb's own omp build: omp's CLI from an ompweb-dev/oh-my-pi integration release (an upstream omp release plus the PRs it carries), with ompweb's channel instead of omp's RPC mode. It reads the same ~/.omp settings, logins and sessions. Each release attaches ompweb-omp-<platform> for linux-x64, linux-arm64, darwin-x64, darwin-arm64 and windows-x64, with their SHA-256 sums; every install, npm and npx included, downloads the one of its exact version on its first start, checks it and keeps it (beside the single binary, otherwise in <agent dir>/omp-web/omp/<version>/), and ompweb fetch-omp does so on demand. Sessions start once it is there. On any other platform ompweb cannot start sessions. The release archives do not contain it; prerelease archives do. omp updates with ompweb: both updaters fetch the new version's runner before its preflight. OMP_WEB_OMP_BIN now points at another ompweb-omp build, for example a copy of the release asset on a machine that cannot reach GitHub: a stock omp does not speak the channel and cannot run ompweb's sessions. On Linux and macOS, ompweb-omp run in a terminal works like omp's TUI, and its session also shows up live in the web.
• Link protocol 11 only. Web servers and host daemons on this release speak link protocol 11 and refuse every older peer, prereleases on protocol 10 included: update the web server first, then every host. Until a host is updated, Settings → Hosts says it needs an update and no session starts there.
• Every host needs one manual update. A host daemon on an older release speaks link protocol 10 or below, so a web server on this release refuses its link, and Settings → Hosts cannot update it (an older web server cannot either: its hosts refuse a candidate on a newer protocol). Update each host by hand once, after the web server: for npm, restart its ompweb host or service (npx @kahme247/ompweb@latest picks up the new version; a global install needs npm install -g @kahme247/ompweb first); for a single binary, stop ompweb host, replace its directory with the new release and start it again. Either downloads its ompweb-omp on that start. Later updates from Settings → Hosts work, and fetch the new version's runner before its preflight.
• The service installers no longer pin a stock omp. ompweb systemd install and ompweb-launchd install used to write the omp found on PATH into the service environment as OMP_WEB_OMP_BIN, which would now make every session fail. They write OMP_WEB_OMP_BIN only when you set it yourself. Reinstall the services after updating if your service environment (~/.omp/agent/web-service.env, the unit or the plist) still names a stock omp.
• Skill startup notices and "View skill diagnostics" are gone. They needed omp commands that only an unmerged omp PR had; the notices above the composer, the Settings → Interface & Behavior switch and the Skills panel's View skill diagnostics are removed.

Added

• A distinct ompweb icon. The rounded π inside an open orbit retains the pink–purple–cyan palette. The sidebar logo, SVG/PNG artwork, favicons, installed-app icons and tray icon now use the same mark.
• Upgrades check the session omp before they switch. ompweb preflight resolves omp exactly as the host does for a new session (OMP_WEB_OMP_BIN or this version's downloaded ompweb-omp), starts it headless with --no-session, and waits up to 30 s for its hello: it prints preflight ok: <omp> <version>, or exits 1 naming the binary and why (not found, not executable, exited with its code, or no hello with omp's last stderr). The host updater and the web app's in-app update run the new release's preflight in the live environment before they stop anything, and abort with the current install still running when it fails. Before the preflight, both run the new release's ompweb fetch-omp, so its runner is in place first. A release without the preflight command is checked only if it ships ompweb-omp; then the update fails.
• Rename the cluster. Settings → Hosts shows the cluster's name with a Rename cluster button; the sidebar group follows. The cluster is still created as "Cluster" when the first host joins, so rename it afterwards. PATCH /api/hosts { poolId, label } renames a pool without replacing the pool registry.
• Cluster members use this machine's omp configuration.
  Before upgrading: every cluster member needs an ompweb host daemon at link protocol 10. Until a member's daemon is updated, sessions cannot start there (the start is refused and names the update), cluster placement skips it, a host below protocol 10 cannot join, and Settings → Hosts says it needs an update. Once its daemon is updated, every host already in the first pool receives this machine's configuration, secrets included (API keys, MCP environments and headers, tokens), automatically and without a confirmation having been shown, and its own omp configuration is replaced until it leaves the cluster; it is kept in <agent dir>/omp-web/own-config/ on the member and put back on leaving. To avoid that for a host, remove it from the first pool (PUT /api/hosts, or editing ~/.omp/agent/omp-web/pools.json) before updating its daemon. Update the web server first, then the members.
  A cluster session now runs with this machine's settings (config.yml, without the machine-specific keys), models.yml, MCP servers, skills, task agents, rules and context files, commands, prompts, hooks, extensions, custom tools, secrets.yml, .env, the agent environment variables of Settings → System, and the installed plugins, whichever member it runs on. A change made here, in Settings or on disk, reaches the members within about a minute and before every session start on a member. Every cluster session start carries this machine's version: a start that must run on one member is refused with the reason when its files cannot be applied, and new sessions are placed only on members with the current configuration and plugins; a session recovered after a daemon restart, or started by another ompweb server, runs on whatever is on the member's disk, and running sessions are not restarted. A mirrored directory becomes equal to this machine's. The member's backup holds only what the host had when it joined: a file it adds or edits afterwards is deleted at the next apply, not backed up. Settings that describe the machine itself stay the member's own as they were when the host joined (see the README). A host holds one ompweb server's configuration: a host already in another server's cluster cannot join (409 host_in_other_cluster), and a member that also runs sessions for another server runs them on this one's configuration. The configuration contains secrets, which are written to every member's disk, readable by the daemon's user only; the hooks, extensions, tools and plugins in it run on every member, and this machine can already start omp with full tool access there. Each file is limited to 5 MiB and the configuration to 50 MiB; a configuration over a limit, or one that cannot be read, is not mirrored at all, a cluster session start on a member is refused (409 cluster_config_invalid), placement skips every member, and Settings names the file. Each download has a 30 s limit including the body (a 5 MiB file needs roughly 1.4 Mbit/s). An apply is refused on a member where ~/.agents is a symbolic link, and the mirrored directories and the backup must be on one filesystem. The reverse proxy must pass /api/hosts/cluster-config/manifest and /api/hosts/cluster-config/file/<hash> without its own authentication, at exactly these paths (unlike the broker's prefix).
  Plugins are installed (this needs bun and network access on the member), removed and enabled or disabled on each member by omp plugin: npm plugins are pinned to this machine's version, marketplace plugins have no version pin in omp, and a failing install leaves the member not current and is retried. Leaving puts the member's own configuration and plugins back; if that fails Settings says so, and it is retried while the host is linked. Revoking a member does the same: its daemon puts its own configuration back at once if it is connected, otherwise the next time it reaches this machine. Settings → Hosts shows each member's state (same as the master, updating, failed with the reason, held by another server, needs an update) and the MCP server commands that are not installed there, and names the file when this machine's configuration cannot be mirrored (the member lines then do not say updating). For a session on another member, the MCP, Skills, Plugins and Agents screens act on this machine's user-level configuration, and say they apply to every member, as does Settings → System next to the agent environment variables in a cluster session; MCP shows that session's live status read-only, and the session's MCP switches, reload and Skills diagnostics are not available there. GET /api/plugins, POST /api/plugins, GET /api/skills, POST /api/skills/check and POST /api/skills/update now accept a request without cwd for the user level, and GET /api/mcp?attach=1 reads a running session's live MCP status without starting one. A provider in models.yml that points at this machine's own address, MCP servers started by a command, and API keys written as an environment-variable name or !command need what they refer to on each member.
• Cluster membership in Settings. There is one cluster, the first pool in pools.json, and this machine is its master. Each linked host has an In the cluster switch in Settings → Hosts; turning it on asks for the folder on that host where the cluster keeps the checkouts it creates and says what changes, turning it off asks for confirmation. A host can join while it is onlin...

2026-11-14T10:33:20Z

Binaries built from 1f4a4bb (feat(github): agent tools to watch, read and answer GitHub pull requests and issues (#477)), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.

2026-11-14T10:12:25Z

Binaries built from 13d8eb2 (feat(outbox): retry a held message that was not sent (#476)), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.

2026-11-14T09:14:07Z

Binaries built from 068ec4d (fix(hosts): preserve maintenance across protocol upgrades (#492)), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.

2026-11-14T07:06:43Z

Binaries built from 22394e3 (perf(panels): coalesce scrolling and resize drag updates), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.

2026-11-14T06:51:46Z

Binaries built from 450f398 (feat(sidebar): add session context menu and action shortcuts), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.

2026-11-14T04:17:32Z

Binaries built from 3a56e79 (fix(test): resolve updater runner fixture version dynamically), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.

2026-11-14T03:59:36Z

Binaries built from b61a3a0 (fix: stabilize linked sessions and CI concurrency tests (#489)), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.

2026-11-14T03:39:12Z

Binaries built from f62302a (fix(chat): preserve preformatted ask text (#487)), omp: ompweb-dev/oh-my-pi v18.20.0-int.202611131515.g11d9dc7. Not a release: no npm package, no update notice.