omnigent-ai/omnigent

Description If you set a custom font in Settings → Appearance, the sidebar section headers ("Pinned", "Projects", "Sessions") don't use it. The session rows and the rest of the UI do. The headers stay in the system sans-serif font, so the sidebar shows two fonts. This happens in the desktop app when it's connected to a Databricks-workspace-hosted Omnigent. The headers are elements, and the host page's heading styles override the inherited UI font. Steps to reproduce Open the Omnigent desktop app connected to a workspace-hosted server. Go to Settings → Appearance and set the font family to a distinctive font (e.g. Berkeley Mono or Georgia). Look at the sidebar: the session titles change font, but "Pinned", "Projects" and "Sessions" don't. Version desktop 0.17.2 OS macOS Harness No response Harness mode No response Platform or device No response Observed impact None Authentication type No response

Summary For agents presented as a terminal, the runner hosts an omnigent attach REPL in a tmux pane and defers starting it until a client first attaches. That keeps never-opened terminals cheap. But nothing reacts when the last client leaves: once the terminal has been opened once, the REPL keeps running and re-renders its full prompt_toolkit screen on every session event for the rest of the session. On a busy session that costs about 12% of a core per REPL, nearly all of it prompt_toolkit layout and rendering. The renders are also heavier than they need to be: about 200 terminal-size ioctls a second against about 12 writes a second. What happens On main @ d98b5a7: _auto_create_repl_terminal creates the session's terminal running omnigent attach, embedded in the web UI over the terminal-attach WebSocket. Its docstring gives the cost model: "a session whose terminal is never opened pays only for an idle tmux pane". That works through tmux_start_on_attach: the pane command becomes tmux

Summary The CLI REPL's sub-agent navigator rebuilds the sub-agent tree by calling GET /v1/sessions/{id}/child_sessions once for every node, sequentially, then sleeps 2 s and does it again. There is no server endpoint that returns a tree, so cost grows linearly with tree size and the loop becomes effectively continuous once trees are non-trivial. On a self-hosted deployment with a handful of omnigent attach sessions whose agents fan out sub-agents, this is 65–77% of all requests the server handles, with the single server process at its one-core ceiling. The same per-node pattern is used by the SDK's child_sessions_tree() and the web Agents panel, and the walk has correctness gaps of its own (truncation past one page, archived nodes hiding their descendants). A server-side subtree endpoint backed by the store query that already exists would fix the cost and the gaps together. What happens On main @ d98b5a7: The REPL polls on _SUBAGENT_POLL_SECONDS = 2.0 with _MAX_SUBAGENT_TREE_DEPTH =

Observed impact On native Windows, the host daemon reports a CLI-backed harness (e.g. claude-native) as "not configured on <host>" even though the CLI is installed and runnable — so the harness can't be launched. This happens whenever the CLI lives in a directory that is on the interactive shell's PATH but not on the host daemon's frozen PATH (e.g. ~/.local/bin, where the official Claude Code Windows installer places claude.exe). Root cause omnigent/_platform.py::resolve_cli_binary() falls back to a ladder of global install dirs (_cli_fallback_dirs(), which includes ~/.local/bin) when a CLI is not found on PATH. That fallback is the mechanism meant to survive the daemon's frozen PATH. But it probes a bare name: for directory in _cli_fallback_dirs(): candidate = directory / name # "claude", never "claude.exe" if candidate.is_file() and os.access(candidate, os.X_OK): return str(candidate) On Windows the installed binary is claude.exe / codex.cmd, so directory /

Problem or use case I use the Omnigent desktop app with a local server and Claude Code and Codex installed on my Mac. Keeping these CLIs current requires leaving Omnigent and updating them separately. I would like Omnigent to notify me when a newer harness CLI version is available and let me update it directly. Proposed solution Show an “Update available” notification or badge for installed harnesses, with the host name, installed version, latest version, and an Update button. For an initial implementation, support npm-installed Claude Code and Codex: Check for newer stable releases periodically without blocking normal use. Update the CLI on the selected host using its existing installation method. Defer updates while the affected harness has active sessions. Restrict updates to the host owner. Show progress and actionable errors. Verify the installed version afterward and refresh the harness status. Other installation methods could show manual update instructions until supported