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.

Set what the agent can do without asking

Native coding-agent sessions choose their permission or approval mode from the composer's permissions dropdown — the hand icon next to the input — not from the picker's Edit menu. The Edit menu keeps the model and effort choices; Advanced settings now appears only for agents that have a configurable underlying harness (a bundle agent whose brain harness you can override). The options in the dropdown depend on the selected harness:

• Claude Code (claude-native) offers its permission modes (for example Accept edits or Bypass permissions). The pick rides along as --permission-mode.
• Codex (codex-native) offers its approval presets — Default, Full access, and Read only — plus the most-permissive Bypass approvals & sandbox option. Full access launches Codex with --sandbox danger-full-access --ask-for-approval never; the bypass option maps to Codex's --dangerously-bypass-approvals-and-sandbox stance and is create-time only (a running Codex session switches approvals through its own /permissions popup, which has no bypass row).
• Cursor (cursor-native) offers its execution mode, such as Plan.
• Antigravity (antigravity-native) offers Ask every time or Skip permissions. Skip permissions is a dangerous bypass that runs the session with all tool prompts disabled; while it's selected the composer shows a red warning banner.

Your choice is remembered and seeds the next new session, the same way the model picker is remembered.

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.

Find a session by name

Press ⌘⌥S (Ctrl+Alt+S on Windows/Linux) to jump straight to the Switch session picker — a name-only search over your sessions. Type part of a session's title and the list fuzzy-matches it (for example, fxprs finds “Fix the parser”); press Enter to open the top match. The chord fires even while the composer is focused and leaves any unsent draft untouched when you Escape out; inside a terminal it yields to that surface.

This picker lists sessions only — no commands or actions. It complements the command palette (⌘K), which searches sessions and runs commands. The search loads more sessions as you narrow the query; when there are more matches than fit, a Search older sessions control pulls in older pages.

Other global shortcuts

⌘⇧M is the keyboard equivalent of typing /model in the composer: it opens the model picker without leaving the keyboard. It works both in an existing session's composer and on the new-chat screen, where it opens the agent/model picker and drills straight into the selected harness's model submenu. The chord fires only when a model picker is available to open (it stays inert while the composer is read-only, the session is unreachable, or config is busy), and it yields to surfaces that own their own keys, such as the terminal and the code editor.

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.

Workspace panel default

New chats start with the right Workspace rail collapsed by default, so a session stays visually stable while its runner and workspace hydrate. Expand it at any time from the header's Expand right panel control (or toggle it with ⌘⌥] / Ctrl+Alt+]).

To make new chats open the rail automatically instead, set the Workspace panel default under Settings → Appearance to Open. The two choices are Open and Collapsed. This is a per-device browser preference that only seeds sessions with no saved open-state — once you expand or collapse the rail in a given session, that session keeps its own remembered state regardless of the default.

Default Workspace tab

Choose which tab the right Workspace rail opens on first. Under Settings → Appearance → Default Workspace tab, pick one of:

• Files — the default.
• Changes
• GitHub
• Agents

The tab you pick is shown first in the rail; the remaining tabs keep their relative order. Changing this default also updates existing chats when they're reopened or refreshed, without closing their open file tabs or changing the rail layout. Any manual tab choice you make in a session afterwards is remembered for that session and wins over the default, and file links still open the linked file regardless of the setting.

This is a per-device UI preference stored in your browser. If a chosen default tab isn't available in a given session (for example, GitHub only appears in coding-agent sessions, and Files/Changes need an on-disk workspace), the rail falls back to the first available tab.

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 tracks the pull requests associated with the session and shows the selected one's summary (PR description and comments), CI checks, and a stacked diff with a file-tree navigator. Nothing is pushed or mutated — recording an association never touches the remote PR.

Tracked pull requests

Omnigent discovers a session's pull requests automatically by observing the agent's completed GitHub work — gh CLI commands and GitHub MCP tool calls that create, edit, review, merge, or comment on a PR. Each association is tagged with how it was found:

• created — the session opened the PR.
• worked_on — the session edited, reviewed, merged, or otherwise acted on it.
• attached — you linked it manually (see below).
• inferred — matched from the current branch when the session has no recorded PR yet; shown as (from branch) in the selector.

Associations are stored on the host, independent of the current checkout, so they stay with the session even as its branch or worktree changes.

When a session tracks more than one PR, a selector at the top of the tab switches between them; each entry reads owner/repo #number (prefixed with the host for GitHub Enterprise). The details, changed files, and diff below are always the selected PR's, fetched from GitHub — including fork PRs and renamed files — so they match the PR's "Files changed" exactly.

Link or unlink a PR

Use the + (Link a PR) button to attach a pull request by URL — paste a https://github.com/owner/repo/pull/123 link (GitHub Enterprise hosts work too). The linked PR becomes an attached association and is selected. The trash (Unlink PR) button removes the selected association; an unlinked PR stays out of the list until you link it again, even if the agent keeps touching it. When a session tracks no PRs yet, the tab's empty state offers the same Link a PR action.

The composer status line mirrors this: it shows #123 for a single tracked PR or N PRs when several are tracked, and clicking it opens the GitHub tab.

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.

Side questions with /btw

In a Claude Code (claude-native) session, type /btw in the composer to ask a side question without adding it to the conversation. /btw ("by the way") is a Claude Code built-in, so the composer's slash menu offers it only on Claude Code sessions; selecting it pre-fills /btw so you can type your question after it.

The answer comes back in a dismissable overlay above the composer instead of as a saved message. While the overlay is open the composer is locked — its placeholder reads Side chat open — press Esc to close — so the next input closes the overlay rather than sending a message. Press Esc (or click ✕) to dismiss it.

Side chats are transient and live-only: nothing is written to the transcript and there is no replay, so reloading the page drops the overlay. This matches the terminal, where Escape closes the /btw overlay and leaves no history. Dismissing the web overlay also closes the matching overlay in the embedded terminal, so the two views stay in lockstep.

You can start a side chat from either side — typing /btw in the web composer or directly in the embedded terminal — and the answer is mirrored into the web overlay. If a very long answer is clipped in the relayed overlay, it's flagged as truncated and points you to the terminal for the full text.

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.