feat: activate agent triggers (cron scheduling) in open build

[Flo5k5]

Summary

• Enable the AGENT_TRIGGERS feature flag (scripts/build.ts) to unlock CronCreate, CronDelete, and CronList tools for all open-build users.
• Follows the activation pattern established in feat: activate buddy system in open build #346 (buddy system).

The cron scheduling implementation is complete and production-ready (600+ lines):

• src/tools/ScheduleCronTool/CronCreateTool.ts — create recurring/one-shot tasks
• src/tools/ScheduleCronTool/CronDeleteTool.ts — delete scheduled tasks
• src/tools/ScheduleCronTool/CronListTool.ts — list active tasks
• src/utils/cronTasks.ts — persistence via .claude/scheduled_tasks.json
• src/utils/cronScheduler.ts — local event loop with missed-task detection
• src/utils/cronTasksLock.ts — multi-session lock coordination

The GrowthBook runtime gate (tengu_kairos_cron) defaults to true via the no-telemetry stub, so this works out of the box. Kill-switch: CLAUDE_CODE_DISABLE_CRON=1.

Test plan

• bun run build — compiles successfully
• bun run smoke — smoke tests pass
• Ask the agent to schedule a recurring task, verify .claude/scheduled_tasks.json is created
• Verify CronList shows the scheduled task
• Verify CronDelete removes it
• Verify CLAUDE_CODE_DISABLE_CRON=1 disables the feature

[Copilot]

Pull request overview

Enables the open-build compile-time feature flag for agent triggers so cron scheduling tools (CronCreate, CronDelete, CronList) and related scheduling surfaces can be included in the bundled CLI.

Changes:

• Turn on the AGENT_TRIGGERS open-build feature flag in the Bun bundling shim.
• As a result, cron scheduling modules/tools that are already runtime-gated can be shipped in the open build.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[khaledmoayad]

Hey, can you check PR #621, I think it already solves what youre looking for, and even possibly enhance.

[Flo5k5]

Hey @khaledmoayad, thanks for the pointer! I took a look at #621 — nice work on the /loop rewrite with the four scheduling modes (dynamic/fixed × prompt/maintenance), that's a solid improvement over the current single-mode implementation.

For the cron activation specifically, this PR is part of a broader stack I'm working on to systematically open up the build:

• cleanup: remove dead USER_TYPE branches from non-stubbed modules #637 — dead code cleanup for USER_TYPE branches
• feat: local feature flag overrides via ~/.claude/feature-flags.json #639 — local feature flag overrides via ~/.claude/feature-flags.json (replaces the GrowthBook no-op stub so users can control all ~50 tengu_* runtime gates)
• feat: activate agent triggers (cron scheduling) in open build #633 (this PR) — flip the AGENT_TRIGGERS build flag
• feat: open useful USER_TYPE-gated features to all users #644 — remove 13 USER_TYPE gates (agent nesting, effort max, sandbox config, etc.)

The build flag flip in #633 combined with the local flag reader in #639 gives users full control over both the compile-time and runtime layers — so the isKairosCronEnabled() hardcode in your PR isn't needed (the stub already returns defaultValue: true).

That said, your /loop rewrite with dynamic self-pacing and maintenance mode is genuinely useful and doesn't overlap with anything in my stack. Would you consider splitting it into its own PR? It could land cleanly on top of this once the cron tools are activated. Happy to review it!

[khaledmoayad]

Makes sense — I've stripped the infra changes from #621 and scoped it to just the loop.ts rewrite and tests, so it can land cleanly on top of your stack. PR description is updated.

Would love a review on the skill logic when you get a chance!

[khaledmoayad]

Heads up on something I hit while testing #621 that's relevant here.

Bun's constant folder evaluates feature('AGENT_TRIGGERS') at bundle time through the bun:bundle shim, and the folded value appears to be cached from a previous build. In practice this means flipping the flag to true in build.ts doesn't propagate: the require() blocks inside if (feature('AGENT_TRIGGERS')) still compile to if (false) {} dead code on incremental builds. I confirmed this by checking the output of initBundledSkills() and isKairosCronEnabled() in the bundle — both retained their false-branch forms even after the flag was changed and the build was re-run.

This affects the cron tools in tools.ts, useScheduledTasks in REPL.tsx, and the loop skill registration in index.ts — all three remain dead code in the bundle. A rm -rf dist/ before rebuilding forces a clean evaluation, but that's fragile.

Because of this, I've updated #621 to remove the AGENT_TRIGGERS guards from the specific paths /loop needs rather than relying on the flag flip. It might be worth doing the same in this PR for the cron tools — or at minimum documenting that a clean build is required after the flag change.

[Flo5k5]

Thanks for the thorough investigation on the Bun cache issue @khaledmoayad — that was a really good catch.

Good news: PR #657 addresses this exact problem by replacing the bun:bundle shim with source pre-processing. Instead of relying on Bun's constant folder (which caches across incremental builds as you found), the build script now rewrites feature() calls directly in the source files before bundling, then restores them in a finally block. This makes flag changes take effect immediately on every build — no more rm -rf dist/ needed.

I'll take a look at #621 for the loop rewrite — happy to review it once #657 lands so we have a clean foundation for the flag system.

[khaledmoayad]

Checked #657 — nice fix, the pre-processing approach is much cleaner than fighting Bun's native resolver. Good to know the shim was fully broken rather than just a caching quirk.

Our PRs don't conflict (different files), so #621 can land independently either way. The approach we ended up with — removing the build-time guards and using isKairosCronEnabled() as the sole runtime gate — is actually a reasonable long-term pattern for the open build regardless of how the flag system evolves. Happy to wait for #657 to land first if you'd prefer a clean base though.

[kevincodex1]

Hello @Flo5k5 this is good direction kindly please rebase to main and fix conflicts so we can start review

[Vasanthdev2004]

Review: PR #633 — Activate agent triggers (cron scheduling) in open build (head ee57240)

CI green ✅. 1 file, +1/-1.

Assessment

Flips AGENT_TRIGGERS feature flag from false to true in scripts/build.ts. This enables cron scheduling in the open build.

The feature code is already fully implemented and gated behind this flag. The implementation was reviewed as part of prior PRs. This is a standard feature-flag activation flip — same class as PR #632 (DAEMON flag), PR #621 (AGENT_TRIGGERS initial code), etc.

Note

Per our learning from PR #621: Bun's constant folder evaluates feature() at bundle time and caches the result. This build-time flip is the correct way to activate the feature for the open build. Any GrowthBook runtime gates would need separate handling, but AGENT_TRIGGERS doesn't have a secondary GrowthBook gate.

Verdict: Approve-ready ✅

Low-risk feature flag activation. Code is already implemented and gated; this just turns it on.

[kevincodex1]

hello @Flo5k5 please resolve conflicts

[gnanam1990]

I understand the motivation, but this PR is still effectively a feature enablement switch rather than a narrow bug fix. Flipping AGENT_TRIGGERS on for the open build exposes cron scheduling behavior to all users, and I don’t think the current branch provides enough open-build-specific validation for that rollout. I’d want a stronger behavior, safety, and UX validation story before enabling this globally.

[jatmn]

closing as stale