The agent tool-call path

What it is

An agent does its work by asking to run things — a shell command, a file edit, a write. Omniscio controls everything between that request and the answer, and this page is the shape of that road:

• The guard decides, before anything runs, whether the command is allowed. This is the same protection as Git guardrails: no committing or pushing to a protected branch, no destructive stash, no editing files while the repository is on master. Turn on Developer guardrails and the same rules cover every Claude Code session on the computer, not only the ones Omniscio started.
• The shell runs the command. Each session gets one shell that stays alive and is reused for every command, instead of starting a fresh one each time; the app also points the agent's tools straight at the real programs, so a command reaches git, rg, npm and friends without a chain of helper scripts in front of them.
• The measurement records one row per command with its parts timed separately, so "an agent's commands are slow" becomes a number with a component's name on it.

All three used to be several overlapping mechanisms — multiple guards in different languages, several shell-startup layers, and helper scripts stacked in front of common tools. They are now one road with one owner, which is the whole point of this page.

Where to find it

• The performance screen — Developer Tools → Performance Monitor, or the same scorecard from a terminal with npm run perf:status. The tool-call block says where an agent's time went.
• Settings → Features — the guardrails switches: Git guardrails, and Developer guardrails (machine-wide, off by default).
• Settings → Features → Lab / Hooks — the hook panel, which lists the guards Omniscio injects into a session read-mostly.
• Nothing to install and nothing to switch on for the shell itself: a new session picks it up the next time the app and the session start.

How it behaves

• A refused command never starts. The guard answers before the shell is asked to run anything, and the agent sees the refusal with the rule that produced it, not a generic error.
• A command's cost is the shell's start, not the guard's check. Measured on a developer machine in October 2026, one no-op command took about 2.6 seconds end to end: roughly 0.3 s before the guard ran, a few hundredths of a second for the guard itself, about 0.4 s to get the shell going, and most of the rest inside the AI tool itself. That is why this road is built around the shell.
• A slow session is usually a pinned one. If a session's one-time shell setup misses its hard time limit, that session falls back to a full login shell for the rest of its life — several times slower per command, with no error shown. Omniscio counts those fallbacks and re-points a session where it can; the count is in the performance screen.
• Background commands keep running. A command the agent deliberately leaves running (a nohup, a dev server) survives the command ending, exactly as it would in a terminal.
• Switches exist for every part of the road and each one is listed in one place, so turning a part off is a supported operation rather than an edit to a config file.

For agents

Read the contract before adding a hook, a guard, a shim, a shell wrapper or a kill switch anywhere on this road; the parts and the flow are in the map. The one-line version: one hook entry per event per settings source, one rule engine, in-process or cold and never PowerShell, one shell road with a counted fallback, no wrapper on a hot-path name, config in the repository, switches only in the registry, and every call measured.

Related

• Git Guardrails — the rules the guard enforces on the agent's commands.
• Developer Guardrails — the same rules applied machine-wide, opt-in.
• Hooks — the panel that lists the hooks Omniscio composes into a session.
• Performance Monitor — the screen that says where an agent's time went.