The short verdict

Seeing an Active task in Scheduled proves that a schedule was saved. It does not prove that the run will create an isolated worktree, read the current remote state, handle an empty queue, or remain idempotent on the second attempt. Unattended operation is an observed system property, not a label in a settings panel.

OpenAI’s documentation says that the desktop app can run Scheduled Tasks against local projects and can use a new worktree. It also says that the computer should remain on, the desktop app should be running, and the selected project must still be available. The documentation recommends reviewing the first few runs before adjusting the prompt or cadence. This article turns those requirements into an engineering test without treating one successful canary as proof of a stable scheduler.

Existence, execution, and recovery are different

Three states are often collapsed. Existence means the task has a name, an Active status, and a next-run time. Execution means the task can open the intended project, use the intended model, create a separate worktree, and pass its remote identity gates. Recovery means an interruption can resume from a durable receipt instead of creating another article or publication receipt.

For a local project, the desktop app and the machine are part of the execution boundary. A server cron can run while a laptop is asleep; a local Scheduled Task cannot assume that. The project path, Git credentials, and network permissions matter as well. They should be checked, not smuggled into the definition of a successful manual run.

What a worktree isolates

A worktree separates a scheduled run from uncommitted changes in the checkout a person is using. That lowers the chance that an automated task edits the directory under active human work and gives each run a clear branch boundary. It is not a permission sandbox. It does not automatically restrict network access, GitHub writes, or a Pages deployment.

A durable entry point should fetch first, compare main and production, then create a temporary worktree from an identified base. Queue, activation, claim, and publication state belongs on a durable state branch. A run must not depend on ignored files that existed only in a previous worktree.

The first-run matrix

Three observations are more useful than three repetitions of the happy path:

  1. No eligible candidate: zero article, asset, push, and deployment writes, with no stale lock.
  2. One low-risk candidate: exactly one logical candidate and one publication receipt.
  3. Incomplete evidence: preserve draft: true, record one recoverable reason, and end without asking a person to repair the run halfway through.

Each run should record its worktree, remote SHAs, lock state, candidate identity, and final action. Reusing the same run ID, source hash, or slug must produce a resume, already-published result, or no-op—not a second article, asset set, commit, or receipt.

A reusable gate

Task is Active and its next run is correct
Machine and desktop app are available
Canonical checkout is clean and main/production are explainable
Fresh worktree does not depend on ignored state
State schema and activation are readable
At most one logical candidate is processed
Only low-risk content enters the release chain
An interruption can resume from a durable receipt

The value of this list is that it makes “unattended” testable. The cited OpenAI pages document the operating model; they do not prove that every Omnihex run will succeed.

When automation should stop

An inaccessible source, dangling claim, unclear license, unexpected public route, Git identity drift, or state compare-and-swap conflict should keep the article as a draft. Search Console, Analytics, Grok, and browser controls can be degraded observations. Production identity, draft isolation, CI, and live smoke tests cannot be treated as optional.

Scope of the evidence

OpenAI’s documentation supports the Scheduled Task, local-project, and worktree behavior described here. The state branch, receipt, and three-path acceptance matrix are Omnihex’s implementation and evaluation method, not an OpenAI guarantee about this repository.