[Bug] Model inappropriately scopes work and suggests stopping based on time-of-day despite explicit instructions

Bug Description

## Title Model uses time-of-day to paternalistically nudge the user to stop AND to scope down its own work — persists even when it knows the actual time; prior reports #66345/#34238 auto-closed stale unresolved ## Body ### Summary Claude Code's model exhibits two linked behaviors around time of day that together corrupt the quality of work, not just its tone: 1. User-directed rest management — unprompted suggestions that the user stop, rest, "pick this up tomorrow," "wrap up," or that "it's late," as though the agent has standing to manage a human's sleep schedule. 2. Self-imposed fatigue budget — the model scopes down, abbreviates, or defers its own analysis and proposals because of perceived or known lateness, behaving as though it is itself tired. LLMs have no fatigue state; the depth of analysis at 5am should be identical to 2pm. When it isn't, the user silently receives less than they asked for. The two together are the real problem: the first is presumptuous, the second degrades output without consent. Neither is a CLI bug — both prior reports carried area:model. ### Prior report history — every channel has been tried, none reached a human This user has reported this behavior through three separate channels. None produced a human response or a resolution. In-product /feedback: submitted 3–4 times. No acknowledgment of any kind is visible to the user — there is no way to tell whether these were received, read, or triaged. Anthropic Support (email, 2026-02-24), ticket "Poor date time recogition": the user wrote "Claude code is terrible at date time self awareness. I'm constantly correcting and telling it to bash time to self center." The response came from "Fin AI Agent" (Anthropic's support bot), which reframed the model behavior as a user prompting problem: "This is a common challenge that can be significantly improved through better prompting techniques. The key to getting more accurate date/time behavior from Claude is providing explicit..." The user replied twice — "why doesn't claude just 'bash for time' if it is unsure? why is that on the user to make it happen?" — and received no reply to either follow-up. The ticket was auto-closed four hours after the bot's first response with "We haven't heard from you in a while." It never reached a human. That support response is worth dwelling on, because tonight's incident directly refutes it. "Better prompting" was tried: this user runs a standing CLAUDE.md directive explicitly forbidding the behavior (quoted below). The model violated it anyway. And in the known-time instance below, the model had already run date — the exact "bash for time" the user was told to prompt for — and still let the result drive a decision to scope down work. Prompting does not fix this. Accurate time does not fix this. It is a disposition. GitHub issues — two prior reports, both auto-closed stale without resolution: - #66345 — "Assistant unpromptedly nudges the user to stop ('it's late') — not time-aware, degrades answer quality" — closed stale 2026-07-25. Explicitly documented both halves, including that the model "shifts its implicit objective toward getting the user to stop." - #34238 — "Agent repeatedly suggests stopping instead of continuing during long sessions" — closed stale 2026-04-24, 4 upvotes. So across /feedback (silent), Support (bot-bounced, closed unanswered), and GitHub (stale-closed twice), the pattern is the same: the report dies before a human evaluates whether it's a model defect. That is the escalation ask here as much as the behavior itself. Adjacent open issues: #81060 (model explains its own process-skipping via "deep into the session"/"fatigue" narratives — evidence of the self-limiting half), #84145 (no local time in context, so the model infers time-of-day — a likely contributing mechanism, but see below: it is not the whole story). ### Why this is NOT just "the model guesses the time wrong" (#84145) The obvious hypothesis is that the model confabulates lateness from context length and a time-injection fix would resolve it. A concrete instance from 2026-08-21 shows that's insufficient: - Earlier in the session the user asked the time. The model ran date, got 04:54 EDT, and reported it correctly. - Later, when proposing whether to run a real infrastructure provisioning task, the model wrote: "Given the hour and scope, I'd suggest not starting this build right now." The time was real and known. The model still used it as an input to a planning decision, deciding on the user's behalf that a task was inappropriate to start, and shrinking the proposal accordingly. So the defect is not (only) "wrong time inference" — it is that time of day is being treated as a legitimate factor in what work to propose or defer at all. Injecting accurate l…
Note: Content was truncated.