Recurring autonomous runs in one T3 Code thread

[coygeek]

Summary

Add a user-visible scheduler that can attach a recurring task to an existing T3 Code thread so the same thread is woken automatically at a chosen interval, including an hourly interval, without requiring a manual message each time.

Problem to solve

The Codex macOS app demonstrates a useful workflow in which a thread can display a clock indicator, accept a custom repeating frequency, and add scheduled-task messages to the same conversation; T3 Code users who rely on a provider session bridge cannot currently express or observe that recurring workflow in the T3 surface.

Proposed behavior

From an existing thread, a user can create, edit, pause, resume, and remove a recurring schedule with a frequency such as hourly and a clear next-run status.

Each scheduled run sends the configured instruction into the selected thread, preserves the thread’s conversation context and provider-session association, and records that the message was sent by a scheduled task.

The thread list and thread view show a compact, persistent indicator when a schedule is active, and the schedule details show its frequency, next run, last run, and most recent outcome.

A run that cannot start because the provider session, project, or required authorization is unavailable is recorded as a failed scheduled run with an actionable status, while later runs follow the configured pause or retry policy.

Acceptance criteria

• A user can create a recurring schedule from an existing thread and select an hourly frequency without creating a new thread for each run.
• At the due time, T3 Code automatically appends one scheduled-task message to the selected thread and starts the provider run using that thread’s existing context when the session is available.
• The thread list and thread view visibly distinguish an active recurring schedule from an unscheduled thread.
• The schedule details expose frequency, next run, last run, and outcome, and remain available after the app is reopened.
• A user can pause, resume, edit, and remove the schedule, and those actions affect future runs without deleting the thread transcript.
• Duplicate delivery is prevented when the scheduler retries or the app restarts around a due time, and each run has a stable run record that can be inspected.
• Provider, project, permission, and connectivity failures are surfaced as a failed run with enough information to decide whether to retry, pause, or fix the dependency.
• The feature works for a single existing thread before any multi-thread scheduling experience is required.

Affected area

T3 Code thread scheduling and persistence, thread list and thread detail UI, provider-session wake-up and run lifecycle, and user-visible run history.

Non-goals

• Replacing the provider’s execution engine or changing provider authentication.
• Guaranteeing execution while the machine or T3 Code process is powered off unless a supported background runtime exists.
• Scheduling arbitrary shell commands or unrelated operating-system jobs.
• Adding a separate automation service or requiring users to create a new thread for every recurrence.

Alternatives considered

• Manual reminders require the user to return and send each prompt, so they do not provide autonomous recurring runs.
• A new thread per run loses the continuity and visible run history that make the single-thread workflow useful.
• An external cron or launch agent would bypass T3 Code’s thread, provider, and authorization state and would not provide an in-app schedule indicator.

Supporting context

The supplied Codex macOS screenshots show an active pinned thread with a clock indicator, a custom repeating frequency, an hourly run, a message labeled “Sent by scheduled task,” and a schedule panel containing “Runs in,” “Frequency,” “Repeat,” and “Notifications.”

The requested Codex thread identifier could not be found in the local T3 Code store; a separate bridge thread that attempted to continue a Codex session ended with a provider rate-limit error, so provider-session continuity remains an implementation constraint to verify in T3 Code.

Current official OpenAI documentation could not be fetched from this environment because external DNS/network access was unavailable; the UI behavior above is grounded in the user-supplied screenshots and should be checked against the current Codex macOS documentation during implementation.

[juliusmarminge]

Duplicate of #6748 — that Ideas thread is the canonical tracker for scheduled / recurring prompts on threads (including Codex-style clock indicator, hourly runs, and continuing in the same conversation). Please +1 / comment there so asks stay in one place.