How to Schedule a Coding Agent in Open WebUI on a Home Server

Open WebUI v0.13.3 can schedule a coding agent against a selected terminal and working directory. Start with a report-only task in a disposable checkout: run a known test command, summarize failures and send the result back to a chat. That test verifies the scheduler, permissions and delivery path before you give a recurring job access to important files.

You need a compatible Open WebUI installation, a reachable terminal integration that offers the intended agent, and an accessible workspace. The v0.13.3 release notes say scheduled runs check that their saved terminal and agent are still available. Treat the terminal, filesystem and underlying model connection as separate parts of the setup.

What did the November release change?

The automation editor can select a terminal and directory, then choose an agent offered by that terminal. The configured terminal and folder carry into the scheduled run. Agent automation results go to a chat, whereas other automation types can have different destination options. The earlier v0.13.1 release introduced coding agents in the model picker when a connected terminal offers them.

A selected terminal can run on the same host as Open WebUI or be a separate reachable service. The terminal's filesystem is the one that matters for the job. A directory shown on your laptop may be absent in a container. A file available to one terminal may not exist in another. Verify the path in the exact terminal selected for the automation.

How should you prepare the workspace?

Create a dedicated test checkout, ideally for a small repository with no production secrets. Pin a known revision and put a harmless passing test and a known failing test in the setup. For the first report, expose the input checkout read-only if the test runner supports it. Provide a writable scratch location for test caches and logs. Some build tools insist on writing to the tree, so configure them to write elsewhere or use a throwaway writable copy.

If you share one repository between multiple jobs, create one worktree per agent or task. Keep backups and the working directory separate. Read why backups can fail with shared access before granting a task broad write permissions on a file server.

How do you configure the first scheduled job?

Open the automation editor in a release that includes agent automation. Select your terminal, select the directory visible from that terminal, then pick the agent. Use a near-term one-off run for the first test where your installation offers that scheduling option. Read the schedule in your configured time zone. Set a modest runtime or step budget using the controls available to your agent and deployment.

Give the job a concrete input, command and result format. For example:

Inspect the checkout in the selected working directory.
Run the existing local smoke-test command once.
Report the command, exit status, and the first failing test.
If the command or folder is unavailable, report that failure.
Do not install dependencies, change the repository, or contact external services.

Instructions guide the agent. Enforce filesystem and network boundaries separately through the terminal and container configuration. Confirm that a missing dependency leads to a clear failure rather than an unexpected install. The Open WebUI documentation is the starting point for terminal and administrator settings.

What should you verify after the first run?

Open the resulting chat and check the agent identity, working path, test command, exit status and which revision was tested. Compare the result with a manual run of the same command in that terminal. A completed automation only shows that the workflow finished. The report still needs evidence that it actually executed the intended test.

Test a failure path deliberately. Point a test job at a harmless missing input or stop the disposable terminal briefly and observe the resulting state. Restore it after the test. An operator should be able to distinguish unavailable agent, missing directory, failed test and model timeout without reading an entire chat transcript. Verify that the next legitimate run doesn't silently reuse stale output.

Does self-hosting Open WebUI keep code local?

Open WebUI and its terminal can be self-hosted while the selected coding agent uses a remote model. Determine where the agent sends system prompts, file excerpts and test logs. Check its provider configuration before connecting a private checkout. Store provider credentials in the service's designated secret configuration and avoid sharing them through prompts or logs.

Start with a local model endpoint if your requirements prohibit external processing. Verify the endpoint and the agent's fallback configuration, then check any network restrictions that apply to the terminal. For more on limiting exposure, use this guide to AI vulnerability triage and secrets.

How should a report-only job become a recurring workflow?

After successful and failed first runs are both understandable, add a recurring schedule that does not overlap another job using the same directory. Give reports a timestamp and repository revision. Keep alerting simple: surface failures that need action and retain enough context to reproduce them. Periodically check that agent credentials, terminal connectivity and the scheduled directory still work after upgrades.

If you later permit patches, keep them in an isolated branch and require review before merging. A scheduler retry can otherwise duplicate side effects. A report job is easier to retry because it writes only a result, while dependency updates and deployment commands change state. Treat that transition as a separate permission decision.

FAQ

Which version added agent automations?

The relevant feature is listed in Open WebUI v0.13.3. The agent-picker feature in v0.13.1 is related but separate.

Why does the agent not appear in the picker?

Check that the selected terminal is reachable and advertises that agent, and that your installed version and account permissions expose the feature.

Can I pick a folder from my laptop?

Pick a path on the terminal that will actually run the job. Mount or copy the checkout there first if needed.

Does an automation result go to a channel?

The v0.13.3 notes specify chat delivery for agent automations. Check the current version's options before relying on any destination other than that chat.

What should I do if two runs overlap?

Use separate worktrees or choose a schedule and runtime budget that prevent overlap. Inspect any run that used the wrong revision before trusting its report.

Conclusion

Use one terminal, one scoped working directory and one small report-only job to validate the whole path. Verify the model provider, test both success and failure, and keep production credentials outside the terminal. Once the result is repeatable, the same setup can handle recurring repository checks.