Automations

An automation starts an agent session on a schedule, or when you choose Run Now. The agent host runs it, not the window: schedules are evaluated and sessions created by the host, so a run does not depend on the Agents app being open, as long as the host is running.

Maturity

Automations are experimental. They come from the agents window of Code - OSS. The setting chat.automations.enabled is tagged experimental (on by default), and the run timeout setting is offered only in pre-release builds. Neural Inverse has not documented them as verified beyond that.

Two consequences of Neural Inverse's design matter for automations:

• Nobody attends a run. Any action your organisation's policy says needs approval is refused in an automation run. Design the task so it needs only allowed actions, or expect those steps to fail.
• The host must be running. On macOS the shared agent host keeps running after you quit the apps and stops on its own once idle. On Windows and Linux each app runs its own host by default. Restart and recovery follow the host's own rules.

Create an automation

1. In the new-session composer, choose the Automation option, or open Automations from the Customizations sidebar.
2. Write the prompt. It is the only required field: an empty name is taken from the prompt.
3. Choose the Target: the agent host, the agent, and a workspace with its isolation choice (a worktree or a branch). Without a workspace the target is No workspace.
4. Choose the agent and model inside the prompt input, and the execution mode and permissions below it.
5. Choose the schedule: manual, hourly, or a five-field cron expression in your local time zone.
6. Save. The dialog stays open until the host accepts the definition, and shows a rejection inline.

Saved configuration (model, agent, permissions) is a preference, not a permission grant. It is checked again against current models and policy for every run.

Under Advanced, choose which of your enabled plugins the host copies for the automation's runs; entries changed since they were saved are marked outdated.

Run and observe

• Run Now asks the host to start a run. If a run is already active, it is reported and no second session is created.
• At most one run is active per automation; a run is pending, running, completed or failed. A cancelled run shows as failed with its cancellation reason.
• chat.automations.runTimeoutMinutes ends a run that takes too long, so a hung run cannot block later ones.
• Run sessions do not appear in the main sessions list; you see them in the automation's history.
• Disabling an automation's schedule keeps Run Now. Turning off chat.automations.enabled stops new runs without deleting definitions or stopping sessions already running.

An MCP server that needs sign-in during a run uses a token only if you already signed in to it and allowed it; otherwise the run continues without that server.

Share automations

Automations can be exported and imported as .automation.md blueprints (name, prompt and schedule only, never the target, configuration or history). Imported automations and plugin templates start disabled, and you choose the host and configuration when you review them. Duplicating an automation to another host leaves the original running until you disable it.

Governance and audit

Each run is an ordinary agent session in the agent host: every tool call, command, file write, network access, MCP server and model is decided by your organisation's policy and recorded in the activity record. When the policy requires an intent for the repository, sessions there are refused until an intent is set for it. See Approvals and governance.