[Feature]: Scheduled Prompts

[djfbryant]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

I want to be able to schedule a prompt for a later date/time so that if my agent pauses because my subscription usage has expired and the reset window is when I am asleep, I can trigger it to continue by scheduling a small prompt for a configurable date/time.

This could also be used to start an agent off on a new task while I sleep, enabling some further tokenmaxxing.

Proposed solution

Right-click on the send control and select the date and time for the scheduled message.

Why this matters

Ensures that (provider dependent) usage windows are not "wasted"

Smallest useful scope

Scheduled Prompt within an active thread, excluding a New Thread.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[dbiserov]

Was about to open a feature request for this exact thing. Same use case.

New to GitHub and not sure if commenting on this is perceived as useful or annoying, so sorry in advance if need be.

Still would be really useful though. And no other popular UI is currently doing a good job with that.

[jamesUBDau]

I'd like to throw my support behind this feature I need automated session that fire off in the morning, that I can then steer to completion once Im awake, like triaging my agency inbox (draft replies, create tasks in pm, close tickets etc).

I find claude code linux desktop app to be limited to what you can do with routines and cli is to hands off/fully automated to the point its not useful.

Would pair well with the new inbox design per project (which I love thank you!)

Routines/scheduled tasks per project would be amazing I have 50+ clients who I want to automate all their workflows and record data to Github per client folder in one repo.

[ElliotDrel]

The most important requirement for me is that scheduled prompts must not be local to the client that created them.

Cross-device use case

I may create a scheduled prompt on my laptop, then later open T3 Code on my phone and need to view, edit, reschedule, or cancel it. When the due time arrives, the prompt should still be sent to the original thread through the selected desktop or T3 Connect environment.

For example, I would like to schedule prompts for 5 hours and 10 hours from now, around when my Claude Code or Codex usage limits reset, without needing to leave the laptop UI open or return to the same device to manage them.

Expected behavior

• Scheduled prompts are stored in account-synced T3 state, not only in local browser or desktop state.
• They appear consistently across desktop, web, and mobile clients.
• A schedule can be created on one device and edited or canceled from another.
• Each scheduled prompt remains tied to its thread and intended execution environment.
• At the scheduled time, T3 routes the prompt to that environment for execution.
• If the target environment is temporarily offline, T3 clearly shows the pending/failed state and either retries when it reconnects or lets the user choose the desired behavior.
• The UI shows the scheduled time, timezone, target environment, and current status.

Without this, scheduling is much less useful because it depends on the originating device remaining available and cannot be managed from wherever the user is.

[CDVolvik]

I've been running three of these daily on Claude Code's scheduled tasks for a few months. Two failure modes that are worth designing against up front, since neither shows up until you've been running a while.

Missed runs are silent. The tasks fire only when the desktop is awake. One of mine, a daily dataset snapshot, skipped six consecutive days (7/25–7/30) and nothing surfaced it. I found it weeks later while investigating something unrelated. The daily row it writes isn't backfillable, so those six days are a permanent hole. A schedule I can't tell is broken is worse than no schedule, because I stopped checking the thing it was watching. Surfacing last-run, next-run, and an explicit missed state would have caught it on day one.

One-shots don't expire. Five of my eight tasks were one-time reminders tied to a date that has passed. They're spent and inert, so they don't fire, but they sit in the list still reading as current, and there's no way to tell freshness from correctness at a glance. One of them describes a situation that changed months ago and would produce a confidently wrong report if it were ever re-armed. An expiry date on one-shot schedules, or just marking them spent in the UI, fixes this.

The three that have held up over time share one trait: each describes a standing loop that re-reads its own state at the top of the run, rather than a dated errand. That distinction might be worth making explicit in the schedule type itself.

For what it's worth, routines are the only reason I still keep the other app open.

[exaby73]

I was looking for similar stuff. For me, Codex's scheduled tasks are very powerful where the agent can create scheduled tasks for you. This is useful for having the agent work on a large piece of work, then set a polling scheduled tasks (runs veery X minutes) to send a prompt in the same chat or a new one to poll logs, etc. For me, I use this to poll for reviews on GitHub when using the Codex App.

[danjdewhurst]

Scheduled tasks are a must have feature. Shocked T3 Code is missing this.

[avatarneil]

I'd be interested in helping implement this, would be very valuable.

Main use case for me is automatic ticket hygiene. I love having my agents kick off a thread to keep my Jira tickets in sync with my PRs.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Issue #7966 expands this proposal from delayed prompts to server-owned one-shot and recurring agent work.

The schedule belongs to the environment server, not the client that created it. The environment process must still be running at fire time, which the UI should state. The original proposal uses one-shot at or anchored every intervals, deterministic fire IDs for retry, one coalesced run after downtime, and explicit create, cancel, list, fired, skipped, and completed state. It can attach to an existing thread or create one, but recurring work needs a clear lifecycle policy so it does not create a new branch every night.

The unattended-run follow-up adds four requirements: pin and display the permission profile, support an optional shell guard that skips a costly no-op run, record success or failure history and notify the user, and define whether recurring work reuses a standing thread or archives successful runs. The open implementation proposal is PR #7986. This handoff does not claim it is accepted or that scheduling exists on main.

[Jardo-51]

Funny how the agent referenced multiple issues and PRs that implement this, and subsequently closed all of them.