Web UI

The web UI starts automatically with every session. When the server launches, the URL is printed in your terminal. Open it in any browser to get started.

Session management

See all your sessions in one place. Resume any previous conversation, start new ones, switch between them. Switch agents mid-conversation directly from the UI.

Sessions persist across browser refreshes and server restarts.

Session titles

New sessions get an automatic title based on the first message. Rename a session at any time from its ⋯ menu or header menu. To control the format of automatic titles, configure session_title_instructions on the server.

To turn automatic titling off entirely, open Settings → General → Sessions and switch off Automatically name new sessions. When it's on (the default), Omnigent generates a concise title in the background after the first message of a new top-level session; turn it off to keep the default session name and rename sessions yourself. This is a per-user preference stored on the server, so it follows your account across browsers and devices.

Hide unconfigured harnesses

By default the new-chat picker lists every harness and badges the ones that aren't set up on the selected host (for example, a harness that still needs a CLI install or sign-in) so you can discover and configure them. If you'd rather see only the harnesses that can launch right now, turn on Settings › Appearance › Hide unconfigured harnesses. With it on, harnesses the selected host reports as unconfigured are hidden from the picker instead of badged — including the brain-harness override submenu of a bundle agent (though the currently selected brain always stays visible).

This is a per-device UI preference, off by default. It changes only what the picker shows on this browser — no account or host state is touched — and fails open: when no host is connected or readiness information is unavailable, nothing is hidden.

Projects

Organize related sessions into a named Project. Each project is a collapsible folder in the sidebar, keeping a long session list grouped around the work you're doing. Projects don't nest, and a session belongs to at most one. Grouping is the only thing a project requires; the sessions inside it can each use whatever host, agent, and settings you like.

Create a project from the sidebar at any time, including an empty one with no sessions yet, then move sessions into it as the work takes shape.

You can file a session into a project from two places:

• Start a new session already filed there: each project folder in the sidebar has a shortcut that opens the new-chat composer with the session assigned to that project.
• Move an existing session: open the session's ⋯ menu and choose Move session, then search your projects, create a new one, or remove the session from its project.

Removing a session from a project moves the session back to Sessions section, and deleting a project archives all its sessions.

Project settings and defaults

When the sessions in a project tend to run the same way, a project can store its own default session settings so you don't re-pick them every time. Open the project folder's ⋯ menu and choose Project settings, then set any of:

• Host the new session runs on.
• Working directory the agent starts in.
• Default agent for the session.
• Default model, shown only when the default agent is a native coding harness that takes a model choice (Claude Code or Codex). It pins the model new sessions start on — e.g. "Opus for this repo" — the same way the project pins an agent. The pre-filled model is still editable in the composer, and an explicit pick you make there wins over the project default.
• Random worktree, which branches each new session into its own fresh git worktree. This overrides the global default in Settings › Git in either direction: turn it on to force worktrees for the project, or off to opt out even when the global default is on. Left unset, the project inherits the global default.

New sessions started in that project pre-fill the composer from these defaults. Nothing is locked in: every field is still editable before you send, any default you leave unset falls back to your usual settings, and a default that no longer applies (an offline host, an uninstalled agent) is skipped rather than blocking the session. Leave the settings empty and the project stays a pure organizing tool.

Worktree branches

In the new-chat composer, name a branch to run the agent in its own git worktree. Naming a branch reveals a base branch field, the branch the worktree is cut from. Leave it blank to branch off the workspace's current branch.

To avoid retyping the same base, set a Default base branch under Settings › Git. The composer then auto-fills that value whenever you name a new worktree branch; leave the setting blank to turn auto-fill off.

To always start new sessions in a fresh worktree, turn on Always use a random worktree under Settings › Git. When it's on, the composer seeds a fresh randomly-named worktree branch for any new session that lands in a git workspace, so you don't have to name a branch each time. It's off by default.

A project's own Random worktree setting overrides this global default in either direction — a project can force worktrees on, or opt out even when the global default is on. Only projects that leave the setting unset inherit the global default.

Choose the launch model

Native coding-agent sessions carry a per-session Model picker in their launch config, next to the harness's other launch knobs. Both Claude Code (claude-native) and Codex (codex-native) surface it: open the agent's config in the new-chat composer and pick the underlying LLM the harness launches with.

The choices come from the selected host's resolved model catalog, so the list reflects the providers and credentials configured on that machine. The first option is Default — labeled Default (<model-id>) when the host reports a default model — which leaves the harness on its own configured/default model. Leaving the picker on Default omits the override entirely.

Your choice is remembered per harness, so a model picked for Codex doesn't change the model remembered for Claude Code (and vice versa). When you start the session, the selected model rides along as the launch override and the runner uses it at launch. Under a sandbox launch, where no host catalog is resolved, the picker is empty and the harness default is used.

A project's stored Default model (see Project settings and defaults) outranks the remembered per-harness pick while the composer sits on the project's default agent, so a project can pin its own launch model. It only applies when the stored model is still a valid choice for that harness; a retired or unknown id falls back to your remembered pick. An explicit model you pick in the composer always wins for that session.

Shared sessions

On a multi-user server the sidebar splits your session list across two tabs:

• My sessions — the sessions you own. This tab keeps the full sidebar structure: the Pinned section, Project folders, and the Sessions list.
• Shared with me — a flat list of sessions other people have shared with you.

Browser-first mode

If you prefer to work in the browser rather than the terminal UI, one command starts everything and returns:

omni host --background   # start the local server + host daemon, then return

--background spawns the host daemon as a detached process instead of running it in the foreground. In local mode (no server URL) that daemon also owns the local Omnigent server, so this single command is the whole "start everything" step: it starts (or reuses) the local server, waits for it, and prints the server URL along with the daemon's pid and log path. It reuses a healthy daemon if one is already up rather than double-registering the machine.

Open the printed URL (by default http://localhost:6767) and drive the agent entirely from the browser; no further terminal interaction needed. Stop the daemon later with the omni host stop command it prints.

Sign-in still happens in the foreground, before the spawn: pointing --background at an authenticated remote server (for example omni host --background --server https://your-server.databricksapps.com) runs the browser login in your terminal first, since the detached daemon has no terminal to prompt on.

Keyboard shortcuts

The web UI ships a set of global keyboard shortcuts. Press ⌘/ (Ctrl+/ on Windows/Linux) at any time to open the in-app shortcuts overlay, which lists the current bindings for your platform.

Platform-aware modifiers

Each global shortcut is bound to a single command modifier per platform, and only that modifier fires it:

• On macOS the shortcuts use ⌘, and only ⌘ triggers them. The Ctrl variant — and a combined ⌘+Ctrl chord — is inert, so Ctrl-based readline/emacs editing keys (Ctrl+A, Ctrl+K, …) keep working in the composer and terminal.
• On Windows/Linux the shortcuts use Ctrl, and only Ctrl triggers them.

What you see in the shortcuts overlay is what fires: the overlay shows ⌘ on macOS and Ctrl elsewhere.

Switch sessions

Move between sidebar sessions without leaving the composer:

• Previous session — ⌘[ (Ctrl+[)
• Next session — ⌘] (Ctrl+])

The selection wraps at the ends of the list. The bracket chords carry no text-editing meaning, so they fire even while the composer is focused; inside a terminal or the code editor — which bind ⌘[ / ⌘] themselves (indent/outdent, or forwarding to the PTY) — the shortcut yields to that surface.

Other global shortcuts

Jump straight to a pinned session with the command modifier plus a digit (1–9 for the first nine, 0 for the tenth). In a browser tab — where plain ⌘/Ctrl+digit is reserved for native tab-switching — the binding adds Alt (⌘⌥1…, Ctrl+Alt+1…); the installed desktop app uses the plain ⌘1… chord.

Canvas

The Canvas page gives you a spatial view of your work: instead of the linear sidebar list, your top-level sessions appear as draggable cards you can arrange freely on an infinite canvas. Sessions are grouped by project, with one canvas per project, so each project keeps its own layout.

Canvas is off by default. It's a gated release feature: an operator enables it deployment-wide by including canvas in the server's release features (OMNIGENT_FEATURES=canvas, or --features canvas on a Databricks deploy — combine comma-separated with other features like usage_page,harness_install). Once enabled, a Canvas entry appears in the sidebar navigation and the page is served at /canvas.

Install as an app

The web UI is an installable Progressive Web App (PWA). From a supported browser you can install Omnigent to your desktop or phone home screen and launch it in its own standalone window—no separate download or app store required. Look for your browser's install control (for example, the install icon in Chrome's address bar, or Add to Home Screen on mobile).

Installing is optional: the web UI works exactly the same in a normal browser tab. Because Omnigent is a cloud app with no offline mode, the installed app still requires a connection to your server—it does not cache pages for offline use.

Appearance

Open Settings → Appearance to change how the web UI looks. Two controls sit side by side:

• Mode — light or dark.
• Color theme — a dropdown of palettes that restyle the whole UI:
  • Omnigent — the default brand look.
  • Dracula
  • GitHub
  • Catppuccin
  • Gruvbox
  • Nord — arctic frost blues over polar-night neutrals.

Your mode and palette choices are remembered in the browser and reapplied on your next visit. Picking Omnigent clears any palette override and returns to the default look.

File editor

A full markdown editor with syntax highlighting for browsing and editing every file your Omnigent touches.

Your Omnigent drafts a documentation page. You open it in the editor, read it properly formatted, and make direct edits. Your Omnigent generates a config file. You review it with full syntax highlighting.

Use cases: updating documentation sites, reviewing Omnigent-generated plans, editing configs.

Code viewer and diffs

Review what your Omnigent changed before accepting. Syntax-highlighted diffs show exactly what was added, modified, or removed.

Attach a selection to the agent

In a coding-agent session, select lines in the code viewer or a diff and an Attach to agent button appears next to Add comment. Clicking it drops the selected line span into the composer as a chip (shown as @path:start-end), so you can ask the agent about an exact range without copy-pasting it into chat. The chip is delivered to the agent at send time as a path reference — the agent reads the on-disk file directly (no upload). This button shows only for native coding-agent sessions, since those harnesses run in the workspace and resolve the referenced file themselves.

GitHub

Coding-agent sessions have a GitHub tab in the right workspace rail. It's a read-only view of how the session's branch relates to GitHub, backed by the gh CLI and git running against the workspace on disk — nothing is pushed or mutated.

The tab shows two things the associated pull request when the branch has one (PR description, CI checks, and diff).

Mentioning workspace files

In a coding-agent session, type @ in the composer to browse and attach workspace files and folders. Attached paths appear as chips above the input and can be removed individually; the agent reads each one directly from disk at send time.

Appearance settings

Open Settings → Appearance to tune how code renders. Separate from the chrome (UI) font, two controls size and style the code editor (Monaco) and the terminal (xterm) together:

• Code font size — a stepper (− / value / +, or type a value directly). Ranges from 10 to 24 px and defaults to 13 px.
• Code font family — a free-text field: type the name of any monospace font installed on your device. Leave it blank (or use Reset) for the editor default, which falls back to the app's shared mono stack. A custom name that isn't installed degrades to that mono stack rather than a serif fallback.

Both settings apply live to any open editor or terminal — no reload or reconnect — and persist in your browser across refreshes and restarts.

Inline comments and addressing

Instead of typing in chat "change the third paragraph to be more concise," you click on that paragraph and leave a comment: "too verbose, tighten this up." The Omnigent sees exactly what you're referring to and revises it.

Addressing closes the loop: resolve a comment and the Omnigent acts on the feedback. The workflow is: Omnigent proposes, you annotate, Omnigent revises.

Where this matters most:

• Reviewing plans before execution. Annotate the steps you want changed before the Omnigent starts building.
• Editing drafted docs. Leave line-level feedback instead of rewriting in chat.
• Iterating on configs. Flag the fields that need adjustment.

Multi-modal input

Paste images, screenshots, diagrams, and mockups directly into the conversation. The Omnigent sees them alongside your text. Useful for frontend work where describing a layout issue in words is slower than screenshotting it.

Message queue and steering

Type a follow-up while the agent is still working and it's held in a client-side queue instead of interrupting the turn. Queued messages appear in a docked strip above the composer, and drain automatically — one at a time, in order — as soon as the session goes idle.

Each queued row has inline actions:

• Steer — send the message now, mid-turn, instead of waiting for the queue to flush.
• Edit — pull the message back into the composer to revise it.
• Delete — drop the message from the queue.

Scheduled tasks

Run an agent on a recurring schedule instead of starting each session by hand. A scheduled task is a saved prompt plus a recurrence rule: it fires automatically, runs the chosen agent, and keeps firing until you delete it.

To create one manually, open the New scheduled task dialog and fill in:

• Name — a label for the task (for example, Nightly triage).
• Prompt — the instruction the agent receives on every run.
• Runs with — the agent or harness to run. Scheduled tasks use that agent's default model, effort, and permission settings; there are no per-task model or effort overrides in this dialog.
• Frequency — one of four presets: Hourly, Daily, Weekdays, or Weekly. Hourly fires once an hour and asks only for the minute of the hour; Daily and Weekdays ask for a time; Weekly adds a weekday multi-select (On days). Times are chosen in 15-minute steps. The schedule is evaluated in your browser's local timezone.
• Host (optional) — pin the task to a specific connected host, or leave it set to Resolve at fire time to run on your connected host whenever the task fires.
• Workspace (optional) — shown only once a host is pinned. Pick a directory to pin it; leave it unset to default to the host's home directory. A workspace can't be set without a host.

The Create task button stays disabled until Name, Prompt, a valid schedule, and an agent are all set.

Collaboration

Share your session with teammates for real-time co-driving. Multiple people see the same conversation, leave comments, and interact with the Omnigent simultaneously.

See Pair Programming for details on sharing, permissions, and multi-user workflows.