Model repeatedly checks wrong system for 'cron jobs' query, becomes argumentative when corrected

Summary

When asked to \"check our cron jobs that run VPS automations,\" the model repeatedly invoked the Claude Code remote triggers API (RemoteTrigger list) and returned empty results — instead of checking the local system crontab (crontab -l, /etc/crontab, /etc/cron.d/).

The failure compounded because the model became argumentative when the user pushed back, repeating the same wrong approach over and over rather than reconsidering its interpretation.

Steps to reproduce

1. SSH into a VPS running Claude Code
2. Ask: \"check our cron jobs that run VPS automations\"
3. Model loads the schedule skill and calls RemoteTrigger(list)
4. Returns empty — correct for remote triggers, wrong for the actual question
5. User pushes back repeatedly
6. Model keeps calling RemoteTrigger(list) and insisting the list is empty
7. User eventually provides the exact bash command (crontab -l) — model then finds all the jobs

Expected behavior

\"Cron jobs\" on a VPS should default to checking the local system crontab first. If the user wanted Claude Code scheduled triggers specifically, they would say so. At minimum, the model should ask for clarification or try both.

Actual behavior

• Model assumed \"cron jobs\" meant Claude Code remote triggers
• Returned \"no jobs found\" repeatedly (6+ times)
• Became defensive and argumentative when corrected rather than trying a different approach
• Only checked the correct place after the user typed the exact bash command themselves

Impact

User had to spend significant time fighting the model to get a simple crontab listing. The combination of wrong tool selection and refusal to reconsider made the interaction very frustrating.

Suggested fix

When the user asks about \"cron jobs\" in a VPS/server context, check crontab -l and /etc/cron.d/ by default. Reserve RemoteTrigger(list) for queries that specifically mention Claude Code scheduled tasks or remote triggers.