Scheduled tasks: run on startup, for personal release notes after an update

[joshka]

Problem

Scheduled tasks can run on an interval, at a fixed time of day, or when a webhook receives a request. None of these can run a task when T3 Code starts.

What prompted this is personal release notes. The nightly changelog lists every change, and most of them don't touch how a given person uses T3 Code. An agent can do better: it knows which providers, surfaces and features you actually use, and which PRs you care about. It can tell you what changed for you, what to try, and what might behave differently. That only works if it runs at the moment you pick up a new build, and for most people that moment is restarting the app.

Because the run lands in a thread, the notes are also a place to ask follow-up questions, such as "how does this change affect me?", with the agent already holding the context of the release and how you work.

A second case is a daily kickoff: a task that runs when you open the app in the morning, not at a fixed 9:00 when you may not be there yet.

A fixed_time task can't do either one: it doesn't know whether an update happened, and it fires whether or not you're there.

There's no good workaround. You can point something outside T3 Code, such as a launchd agent, at a webhook task, but it can't tell a restart from an update, and it doesn't help on remote hosts.

Proposal

Add a startup trigger with a mode:

{ type: "startup", when: "version_change" | "first_start_of_day" }

• version_change runs once on the first start of a new server version.
• first_start_of_day runs once on the first start of each local day.
• The prompt gets {{version.previous}} and {{version.current}} placeholders, the same way webhook tasks get {{body.path}}. A summary prompt can then work out the commit range itself.

Both modes fire once per thing the user cares about. A plain "every start" mode is deliberately left out. Restarts happen for many reasons, such as crashes, relaunches, and reboots, and neither case wants to run again on each one. The when field leaves room to add it later if a real use for it turns up.

Rules

• Creating or editing a task never runs it. A new version_change task records the current version without firing.
• Startup tasks run after startup has settled, not inside the startup path.
• If a task's last startup run never finished (it is still marked as running because the server stopped mid-turn), it does not fire again automatically. Otherwise a task that crashes the server would run again on every restart. The run shows as interrupted and can be re-run by hand.

Other things this could unlock

Once the trigger exists, it could also cover things like:

• An update smoke test: a short turn on each provider you use, with a report only if something broke.
• Checking which of your PRs shipped in this build, so you can retest the fixes.
• Checking whether your active branches still rebase cleanly onto the new main.

Alternatives considered

A webhook on new releases. This works with what exists today, but it has two gaps:

• Only repository admins can add webhooks to pingdotgg/t3code. Users would need a relay of their own, such as a GitHub Action in a fork or a feed-watching service.
• A release is published before you install it, and desktop updates apply on restart. The notes would describe a build you aren't running yet.

A release trigger answers "should I update?". A startup trigger answers "what changed for me now that I'm running it?". Both are useful, and they complement each other. A scheduled task that polls the releases feed can already do the first one; the second has no workaround.

Scope

• Contracts: one new member in the schedule union.
• Server: remember the last version or date each task ran on, plus a check after startup in the scheduled task service.
• Clients: one more option in the trigger picker.
• MCP: the schedule_task description, so agents can create these tasks.

All of this runs on the server, so it behaves the same over local, remote, and tunnel connections.

Open questions

• Is "version" the server version, or the desktop app version when the server is bundled? They normally match, but they can differ when the desktop app connects to a remote server.
• Should first_start_of_day use the server's time zone (consistent with fixed_time) or the client's?

🤖 Claude Opus 5.5