feat: recurring schedules should be able to run indefinitely (currently hard-capped at 7 days, even with durable: true)

オープン
  • 何か問題がありますか？
#1,115 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
領域
cli

調査の方向性

The issue identifies recurring schedules created through /loop and cron_create, stored in ~/.commandcode/cron/jobs.json, and documents the current seven-day expiry. Start by tracing how recurring jobs are created and where their expiry is enforced; then check how durable affects job lifetime. Done means a durable recurring job continues firing until cron_delete removes it, while the default expiry for conversation-scoped tasks remains as described.

索引モデルが issue の本文から書いたものです。

説明

Problem

Recurring scheduled tasks (/loop and cron_create) are hard-capped at seven days, and durable: true does not lift that cap — it only decouples the job from the conversation lifetime.

From the docs (https://commandcode.ai/docs/background-tasks#scheduled-tasks-and-loops):

Recurring tasks expire seven days after creation. A running fixed task gets one final fire at expiry; a self-paced loop stops when it reaches the limit. Re-create a task before expiry or use an external scheduler when it must run indefinitely.

So a job stored in ~/.commandcode/cron/jobs.json still silently stops firing after a week, even though it was created explicitly as a machine-level schedule. The only supported workaround today is an OS-level scheduler (launchd / cron / Task Scheduler) invoking cmd -p headlessly, which loses the conversation the job belongs to.

Why it matters

Long-lived schedules are the normal case, not the exception: a nightly dependency/security sweep, a weekly report, a daily "check this branch / PR / dashboard" task. A user who explicitly asks for a durable schedule reasonably expects it to survive the month, not just the week.

Other agents already offer this — e.g. Claude's scheduled tasks persist indefinitely — so the 7-day cap is the main thing that pushes users back onto an external scheduler.

Proposal (any one of these would solve it)

  1. Add an explicit lifetime to cron_create, e.g. expires: "never" (or expires_at, max_runs), honored for recurring jobs.
  2. Or make durable: true imply no expiry, since those jobs already live outside the conversation in ~/.commandcode/cron/jobs.json.
  3. Or make it configurable, e.g. { "cron": { "recurringTtlDays": -1 } } in settings.json.

The behavior that matters: a durable recurring job keeps firing until it is explicitly removed with cron_delete. The expiry can stay as the default for conversation-scoped tasks, where it makes sense.

Workaround today

System scheduler plus headless mode:

cmd -p "<prompt>"    # with COMMAND_CODE_API_KEY exported

This works, but it cannot resume the conversation the schedule was created in, and it duplicates the job outside Command Code.

主要言語
言語のデータがありません
スター
4.2k
フォーク
377
平均マージ
1日 17分
マージ済み PR（30日）
7

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CommandCodeAI/command-code のほかの issue

CommandCodeAI/command-code の issue をすべて見る

似ている issue

CLI の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。