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

未关闭
  • 哪里不对？
#1,115 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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 分钟
30 天内合并 PR
7

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

CommandCodeAI/command-code 的其他 Issue

查看 CommandCodeAI/command-code 的全部 Issue

相似的 Issue

更多 CLI Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。