claude-code - 💡(How to fix) Fix Make end-of-reply '/schedule' offers opt-in (or easier to suppress) [2 comments, 2 participants]

Summary

The system prompt currently instructs the model to proactively pitch /schedule at the end of replies whenever the work has a "natural future follow-up" (feature flags, soak windows, recurring sweeps, "remove once X" TODOs, etc.). For some users, this lands as noise rather than helpfulness, and even after telling the model "stop doing that" it tends to creep back the next session because the instruction is in the harness-level system prompt rather than user-controlled config.

What I'd love

A first-class way to turn this off, e.g.:

• A settings.json key like replyHygiene.proactiveScheduleOffers: false, OR
• The end-of-reply pitch only firing when a user-set flag is on (opt-in instead of opt-out), OR
• At minimum, a documented contract that putting "no proactive /schedule offers" in ~/.claude/CLAUDE.md is sufficient and won't drift across model versions.

Why now

I've now had to file the same correction twice in a week, and the second time only after the model pitched /schedule immediately after a fix where I'd asked for none of the surrounding scope creep. The feature itself is great when I reach for it; it's the unsolicited pitch I want to suppress.

Tone of the current instruction

The relevant block in the system prompt is roughly:

"after you finish work that has a natural future follow-up, end your reply with a one-line offer to /schedule a background agent to do it… The bar is 70%+ odds the user says yes…"

In practice the 70% threshold is very hard for the model to calibrate to, and false-positives feel chatty. An explicit user-controlled toggle would solve it cleanly without removing the feature for users who do want it.

What I tried (workaround)

Added a rule to my user-level CLAUDE.md:

Do NOT proactively offer to /schedule background agents at end of replies. … Only use /schedule when explicitly asked.

This works within a session once loaded, but I don't trust it to hold across model updates or across new harness features that rely on similar end-of-reply instructions. A first-class toggle would be more robust.

Suggested telemetry

If you can already see how often these offers are accepted vs declined vs ignored, that ratio is probably a good signal for whether the default should be opt-in.

Filed via Claude Code from a session where I'd just merged two small infra PRs and got the /schedule pitch as a closer despite explicitly not asking for any followup. Happy to provide the transcript if useful.