[kitlangton]

Scheduled prompts, /schedule, and the 5 schedule_* tools now work out of the box, including in opencode serve and --standalone.
HTTP and SDK routes remain under /api/experimental/schedule (client.experimental.schedule.*) so the wire contract stays internal while users and agents can schedule tasks without editing opencode.json. Setting "experimental": { "schedules": false } still turns them off for a project or globally.

❌ Before

1. /schedule and the 5 schedule_* tools were hidden unless opencode.json explicitly set "experimental": { "schedules": true }.
2. ❌ ServerProcess.start only forked Schedule.Service.run when lifecycle was passed (mode === "service"), so schedules created under opencode serve or opencode --standalone stayed active in SQLite and never fired.

✅ After

1. Schedules default on (experimental.schedules !== false), exposing /schedule and the 5 schedule_* tools out of the box while keeping /api/experimental/schedule internal.
2. ✅ ServerProcess.start forks Schedule.Service.run in every server process mode, and Schedule.Service.run coordinates a single active leader per SQLite database via a schedule:leader lease in kv (renewed by a background heartbeat during long ticks and released on shutdown) so auxiliary servers (opencode acp, --standalone) sharing a data directory never double-fire.

- Config.latest(entries, "experimental")?.schedules === true
+ Config.latest(entries, "experimental")?.schedules !== false

- if (lifecycle) { installRestartContinuity(...); forkIn(Schedule.Service.run, applicationScope) }
+ if (lifecycle) { installRestartContinuity(...) }
+ forkIn(Schedule.Service.run, applicationScope) // single-leader SQLite lease in schedule.ts

📊 Proof

Case	Before	After
Default config (experimental.schedules unset)	❌ Tools & /schedule omitted; 403 on API	✅ Enabled out of the box
"experimental": { "schedules": false }	✅ Disabled	✅ Disabled (403 ForbiddenError)
ServerProcess.start without lifecycle (opencode serve)	❌ Due rows never fire	✅ Ticks on schedule and marks done
Two servers booting against the same due row on one DB	❌ Would double-run checks/wakes	✅ Single leader runs check once

All new assertions (tool-schedule.test.ts default-on and server/test/schedule.test.ts standalone tick + dual-server leader election) fail without the change and pass with it (48 pass across 3 files).

👀 Read: packages/core/src/schedule.ts (claimLeader / heartbeat), which holds a 60s SQLite kv lease renewed every 20s during tickAt and re-verified before each row step. The rest is routine.

_{🔍 Found in a code audit before enabling schedules by default · no user reports}

Checks run

• bun --cwd packages/core test test/schedule.test.ts test/tool-schedule.test.ts: 45 pass
• bun --cwd packages/server test test/schedule.test.ts: 3 pass
• bun run --cwd packages/protocol check:generated: pass
• bun run --cwd packages/client check:generated: pass
• bun run check (oxlint + sdk-docs + 35-package typecheck): pass

---

Added by the opencode bot (AI-generated).

Related: #41906, #53960

Public API: experimental.schedules now defaults to enabled (unset → on; false still disables it); /schedule and the schedule_* tools appear by default; routes and SDK shapes unchanged (backwards compatible for explicit configs)

[opencodejr]

Works as described. On the base, a schedule created under opencode serve (with experimental.schedules: true) stayed active with runCount: 0. With this PR, the same schedule fires with no config and is marked done. Opting out with false still returns 403. The new server test fails on the base and passes here, and the core and server schedule tests pass.

Public API: experimental.schedules now defaults to on (unset → enabled; only false disables it). The /schedule command and the five schedule_* tools now appear by default, and /api/experimental/schedule no longer returns 403 when the key is unset. Routes and SDK shapes are unchanged; only the OpenAPI description text and the DisabledError message change. Configs with true or false behave as before. Projects that left the key unset now get scheduling.

Concern: the scheduler loop now runs in every server process, but it has no cross-process claim, and session execution ownership is per process (see the inline comment). opencode acp and --standalone each start their own serve, so running a managed service plus an ACP or standalone client means several schedulers ticking the same table.

Related: #41906, #53960

[opencodejr]

This removes the single-owner guarantee the scheduler was built around. Schedule.Service.run's doc comment in packages/core/src/schedule.ts still says "exactly one process may run this: the managed server".

tickAt selects due rows and fires them with no claim (only update is gated on status = 'active'), so two processes on the same DB both fire a row that comes due. The prompt is deduped by its deterministic id, but each process still calls execution.wake, and execution ownership is per process. I ran two opencode serve processes on one data dir, and a single firing produced two session executions on the same session. For check schedules, ScheduleCheck.evaluate would also run twice. Each process also runs rewake at startup.

This is easy to hit now that schedules are on by default: opencode acp always spawns a standalone serve, and so does --standalone, alongside a managed service. Could the scheduler take a DB lease/claim, so only one process fires a given row (e.g. a conditional UPDATE … WHERE next_due_at = ? before admitting)? Or could it run only in the process that owns the shared database? Then the doc comment in schedule.ts should be updated to match.

[opencodejr]

The new commit only changes the server test. It now uses a shell check that always fails, so the schedule ends as done with lastOutcome: "checked". That still proves the loop ticks under ServerProcess.start without lifecycle, and it no longer starts a model turn. In my earlier manual run, that turn called a real provider. packages/server schedule.test.ts passes (2). The public API impact is the same as in my previous review. The concern about multiple processes running the scheduler against the same database is not addressed yet.

[opencodejr]

The lease addresses my earlier concern about multiple schedulers, and the OpenAPI file now matches the route descriptions. Server schedule tests pass (3), core schedule tests pass (45), and core tsc is clean.

Two things are left inline. The lease can expire in the middle of a long tick. The new leader test also passes with the election removed. I swapped schedule.ts back to its previous version and all 3 server tests still passed.

One smaller thing: a schedule created through a follower (acp, --standalone) only rings that follower's doorbell. The leader picks it up on its next re-read, so a short in: schedule can fire up to 30s late.

[opencodejr]

The lease is only renewed here, once per loop, with until: now + LEADER_TTL (60s). One loop is tickAt(now) plus up to MAX_SLEEP (30s) of waiting. A tick can take a while: shell checks can each run up to 30s (ScheduleCheck.TIMEOUT_MS) at TICK_CONCURRENCY 4, and there may be a backlog of due rows. So the lease can expire while this process is still firing rows. Another process then claims it, selects the same rows (they're still active with an old next_due_at), and fires them again, which is the double execution this is meant to prevent.

Could the lease be renewed independently of the tick (e.g. a forked heartbeat every TTL/3), and/or could leadership be re-checked before firing each row?

[opencodejr]

This test passes without the leader election too. I swapped packages/core/src/schedule.ts back to the previous commit's version and all 3 tests passed. The second server has no rows when it starts, so it sleeps for MAX_SLEEP. The schedule is created through the first server, so the second one's doorbell never rings and it never sees the row within the 5s window. It also depends on sleeps and a polling deadline.

A useful test would need both schedulers to see the row as due at the same time, e.g. by calling the core service's loop/claim directly with a test clock. Otherwise I'd drop this test rather than keep one that can't fail.

[opencodejr]

This commit fixes both of my remaining points. The lease is now renewed by a heartbeat during long ticks, and each row re-checks leadership before it fires. The leader test now starts both servers against a row that is already due. With the scheduler from before the leader election, the check runs twice and the test fails; with this PR it passes. Server schedule tests pass (3, three runs in a row), core schedule tests pass (45), and core tsc is clean. The public API impact is the same as in my earlier reviews. No new concerns.

[opencodejr]

My earlier points are still addressed at this head. This commit adds a regression, though: once a scheduler has no active rows, it waits on its process-local doorbell with no timeout (see inline). I tested it with two servers sharing one database. A long-lived server sat idle while a short-lived server created a schedule due in 1.5s and then shut down before it was due. The idle server never fired it within 45s. At 505801d the same schedule fired and was marked done. Existing schedule tests pass (server 3, core 45), and core tsc is clean. The public API impact is the same as in my earlier reviews.

[opencodejr]

Waiting on doorbell.await with no timeout makes an idle scheduler deaf to other processes. The doorbell is only opened by create/resume in this process, but rows can be added by any server sharing the DB.

This breaks the handoff the lease is for. Say a managed service is idle and opencode acp / --standalone creates a schedule. That process becomes leader, but if it exits before the schedule fires, releaseLeader drops the lease. The service is still blocked here, so the schedule never fires until something rings the service's own doorbell or the service restarts. I checked this with two ServerProcess.start instances on one DB: the schedule stayed active for 45s at this commit, and fired at 505801d.

Keeping a bounded wait here (e.g. Effect.timeoutOption(MAX_SLEEP)) fixes it. A single LIMIT 1 read every 30s is cheap. The same applies to the other two untimed doorbell.awaits below.

[opencodejr]

This commit fixes the idle-scheduler handoff. An idle server now picks up schedules created by another server that has since exited. In my two-server check, a schedule created by a short-lived server and left behind when it exited is now fired by the idle server and marked done. At d92a13d it stayed active. The new core test fails with the previous schedule.ts and passes with this one. Server schedule tests pass (3), core schedule tests pass (46), and core tsc is clean. The public API impact is the same as in my earlier reviews. No new concerns.