The Harness Needs a Human

The answer is in the founding document, and it is not hidden.

The showcase controls are prompts

Omnigent was announced on June 13, 2026 as a meta-harness sitting above the agents its authors already use — Claude Code, Codex, Pi, custom agents — with three pillars: composition, control, and collaboration [2]. Read the two control examples the launch post chose to lead with.

Both terminate in a person. Not in a denial, not in a policy verdict, not in a quarantine — in a prompt. These are the canonical demonstrations of contextual policy, chosen by the authors to show what the layer is for, and each one’s final step is a human deciding.

The repository says it outright. Under the reasons to use Omnigent, the governance bullet reads: create policies to pause for your approval before risky actions, cap spend, or limit which tools an agent reaches [15]. Approval is the first clause of the first sentence the project uses to describe governing an agent. Its policy section restates the same order — policies check every action and either allow it, block it, or pause to ask you first — and the worked configuration example names its own rule approve_shell, pointing at a handler called ask_on_os_tools, alongside a budget that pairs a hard spend cap with ask thresholds described as a soft warning on the way [15].

The front page makes the same choice in pictures: the single image chosen to illustrate control is an approval prompt, its alt text describing a Bash tool call blocked by a session cost budget policy [14]. The artifact representing the control layer is a dialog box asking a person, and the surfaces built to answer it are a macOS app, an iOS app, and an Android app [14] — what you build when the answerer has to be reachable away from the workstation.

That is a coherent design for the product being described. The same post says users often have four or five agents open at once and spend their time copy-pasting between them, and that Omnigent is open source in alpha [2]. The other features named are collaboration features: invite people to view your session, comment on files in its workspace, send commands, reach the same agent from web, mobile, or a native app [2]. The repository’s own list of reasons opens on working with agents from any device including your phone, with sessions following you from terminal to browser to handset [15], and it still carries an alpha status badge [15]. This is a workstation tool for engineers working alongside agents, and it was described as one from the first day.

What the runtime confirms

The interactive assumption is not merely rhetorical. It is in the mechanics.

An approval is an elicitation round-trip. The runtime returns true only on an explicit accept, and decline, cancel, malformed payload, missing field, and timeout all resolve to a denial on the policy-spec path [7]. That scope word is load-bearing: the in-process inner-agent datamodel permits an unbounded wait, where an unanswered approval hangs rather than denying [16]. In the default mode the request is a link to a standalone approval page, and resolution requires edit-level authorization on the session [8][9].

So the gate has an answerer or it has a timeout. That claim was audited rather than assumed. At v0.10.0 no configuration, environment variable, policy parameter, or command-line flag satisfies a policy ASK without a human answering it [16]. The structural reason is the strongest part: the policy engine and all thirteen builtins contain zero references to the inner harness’s permission mode, so they cannot consult a bypass flag even if one were set [16]. The single environment variable on the path, OMNIGENT_ELICITATION_MODE, chooses between a standalone approval page and an inline form — two renderings, both requiring a person [16]. An enumeration of every OMNIGENT_ name in the repository, three hundred and seventy of them, turns up none that enables auto-approval [16], which is thoroughness rather than proof; the structural fact is what carries it.

They closed one, too, and the code says so in its own words. A stray ASK reaching the native hook now maps to deny rather than the older defer, and the comment gives the reason: defer returned control to the harness’s permission mode, which acceptEdits or bypassPermissions would auto-approve, re-opening the very bypass this closes [16]. A non-interactive approval path existed and was deliberately removed. The repository’s own test calls the server-side hold the native anti-bypass [16]. That deserves saying plainly: they found their own bypass and shut it.

The default they chose for waiting says the rest. An unanswered ASK times out after eighty-six thousand four hundred seconds — one day — and the comment explains why: an ASK is a human-in-the-loop gate and should outlive a user stepping away [17]. The same comment names the other case in the same breath, telling headless and unattended agents that want a fast fail-closed to override the value per policy or spec-wide [17]. The default is tuned for a person who walked off to lunch. The unattended operator is told to change it.

Then look at what the engine does to make that person’s life tolerable. A per-session cost approval is routed to the root conversation so approving once covers the whole spawn tree, because a sub-agent runs as its own conversation and would otherwise re-prompt [10]. A per-user daily approval persists to that user’s day record so the checkpoint will not prompt them again that day, including from their other sessions [10]. Both behaviors are approval-fatigue engineering. Daily prompt suppression is engineering for human approval fatigue; it is not evidence of an unattended control path.

Two more details from the front page point the same way. Contextual policies are now summarized there as stateful spend caps, model routing, and risk-based escalation [14] — two of the three are cost functions, and the third is escalation, which terminates in someone. And the sandbox is pitched as the way to run YOLO mode safely [14]. That is the honest name for operating without approvals, and the substitute offered is operating-system isolation rather than a stricter policy. Where the human is absent, containment moves to the sandbox.

The nudge that discards the substrate

One built-in deserves separate attention, because it sits across the seam between interactive hygiene and governance continuity.

detect_task_switch watches for a session drifting to a new task and recommends starting a fresh one, since a long session carries irrelevant context and costs more [11]. As developer advice that is correct. As governance, it is a recommendation to discard session state — and session state is the substrate every contextual policy in the product depends on. The accumulated legs of an injection pattern, the recorded first-message intent, the spend so far: all of it is scoped to the session.

So the same product contains a policy that accumulates state to reason about a session’s history, and a policy that suggests ending the session when its history gets long. Neither is wrong on its own terms. Together they mean the governance record’s lifetime is bounded by a workflow convenience, and the boundary is one a user is nudged toward rather than one an operator sets.

What the product does when nobody is there

The strongest evidence for this dispatch is not that Omnigent assumes a human. It is what the product does at the exact points where it knows one is absent.

Sub-agent workers launch in a headless pane. The repository states the problem in its own words: no human can answer an approval card there, so every edit, write, or shell command that prompts stalls the worker [18]. The resolution was to pass bypass flags to the inner command-line tool — bypassPermissions for Claude, –dangerously-bypass-approvals-and-sandbox for Codex, –yolo for Cursor and Kimi, –dangerously-skip-permissions for Antigravity [18]. For Codex and Cursor this is on by default, opt-out rather than opt-in [18].

Read what that is. Confronted with an operating mode that has no human in it, the product’s answer was to switch off the consent gate belonging to the tool underneath — by default, for two of five harnesses. The containment that replaces it is stated too: full bypass is the only non-stalling stance for the headless seam, because the container is the real boundary [18].

This is not a policy-engine bypass, and the distinction matters. A policy ASK on a bypassed session still parks server-side for a person, and the hook deliberately returns no opinion so the harness’s own permission system still runs — the source says emitting an allow there would collapse two independent gates, the deployment’s policy gate and the user’s consent gate, into one, and that the policy layer must not silence the user’s consent [16]. The design keeps them separate. It is the default posture of the inner gate that changes when nobody is watching.

And in one place Omnigent answers a gate itself. A Cursor session launched with –yolo, –force, or -f has lingering in-pane prompts auto-accepted by Omnigent’s runner, which sends the keystroke. It is carefully bounded — only while the pane shows Cursor’s accept hint, capped at three attempts, falling back to a human-visible card on any uncertainty, and questions are excluded because a question is human input rather than a gate a y can answer [19]. The documentation is candid about what it costs: because a gate answered this way is never seen by a human, the accept logs the tool name and an argument preview at info level, and that line is the only record Omnigent approved the call [19].

One log line. Readers of the prior dispatch will recognize the shape — an operational record standing in for a decision record.

What Databricks says about the unattended case

To their credit, they draw the distinction themselves. In the intent-authorization post, an interactive agent gets its intent from a human at the start of the session; an autonomous agent gets its intent pinned at design time in the agent spec, immutable at runtime [3]. That is two operating modes, honestly labeled.

Three things need separating before that distinction can carry any weight, because they are routinely collapsed. Autonomous initiation means the agent starts and proceeds without a human prompting each step. Unattended execution means no human is present during the run. Human-unavailable execution means no human can be reached at the moment a control needs one. Autonomous initiation does not imply the third: an autonomous agent may perfectly well pause and wait for an asynchronous approval, and nothing in this dispatch says otherwise. But if it does, the control’s guarantee has become conditional on someone being reachable — which is a different property from a control that holds whether or not anyone is.

And the autonomous mode is stronger in exactly one respect. Spec-declared policies return with a null id and cannot be patched or deleted through the session-policy API [12], so the design-time intent really is immutable — the finding the prior dispatch credited.

But immutability is not the whole control surface. On the unattended path, what remains of the three verdicts? Allow and deny are predicates and they work without anyone present. Ask is the verdict that requires an answerer. And the classifier that decides whether to raise an ask abstains five ways, including when no model client is configured [13]. So for an agent running unattended, the effective surface is deterministic predicates plus a judgment control that fails open, and the human-in-the-loop layer — the part that is genuinely well built — holds only while someone is reachable. That makes its guarantee conditional rather than structural.

And execution without a locally present operator is not hypothetical in this product. The repository offers cloud sandboxes on Modal or Daytona, described as requiring no laptop, with the server provisioning a sandbox per session as a managed host [15]. That makes running without a local operator first-class and documented — while the sentence describing what governance means still ends in your approval. It does not remove the human; it relocates them. Which is precisely why the approval surfaces are a web UI, a desktop app, and two mobile apps: the answerer has to be reachable from somewhere other than the machine doing the work.

The assurance case does not transfer. It was built for a session with a person in it.

Where the collaboration model points

The permission model tells the same story from a third direction.

Managed Omnigent offers two levels when sharing a session: Read and Edit [5]. Edit is described as full control — send messages, open shells, edit files in the host file system, rename the session — with the caution that an editor can run shell commands and modify files on the host through the agent, and can also view your other session chats [5]. That is a model designed for colleagues, not for services. The repository is blunter still: a teammate can co-attach to a running session, and their messages execute on your machine [15].

There is a corollary worth stating precisely. Every elicitation resolver reachable in production is human-driven — the resolve route, the events route, a Slack button, the REPL, and the Python SDK client [16]. But the SDK client is an authenticated API client, so anyone holding an edit-level credential can script an accept. That is not a bypass mode; it is an authorized client doing what an authorized person’s client does. It means “a human answered” is guaranteed by credential custody rather than by the gate — which is the same boundary the prior dispatch found when the approver’s identity was spent on the access check and never carried into the resolution.

There is also a question about what an approver approves. The human’s decision is a boolean, accept or decline; when the elicitation carries a schema, the form content is machine-filled from that schema rather than chosen by the person [16]. The consent is real. Its granularity is coarser than the artifact it authorizes. And the project’s own policy introduction tells operators they can simply ask the agent to add a policy, because coding agents receive the tools to do it [4].

There is also a disclosure surface that only makes sense among collaborators. The engine exposes a read-only evaluation path so a read-level participant can run the policy engine against a hypothetical action and see what the decision and its pending writes would be, without writing anything [10]. Multi-user accounts are opt-in as well, enabled by a single environment variable, which the Docker deploy sets for you [15]. A default local server therefore runs without accounts at all — reachable only on the local network, which is the mitigation, and also the assumption. The current release adds a warning that names the failure of that assumption in its own words: a single-user server bound to a non-local interface will serve unauthenticated requests as the local user to anyone who can reach the address [20]. Credit where due — v0.10.0 added the warning, not the exposure. But read next to a resolve route that gates on edit level, it describes a configuration in which requests are served as the local user, so any reachable party inherits that effective authority — including the authority to answer an approval. For a teammate diagnosing why the agent got blocked, that is a good feature. As a property of a governance substrate, it means a principal who cannot act can still probe the control surface — which is a reasonable trade in a shared workstation and a different conversation entirely in a multi-tenant production deployment.