Claude Code 2.1.288: no more time limit locally, three shell blind spots closed

2.1.288 of Claude Code, released on October 2, 2026, looks quiet on the surface, but it touches four things that matter for daily use. First, commands launched in the background lose their time limit in the terminal, the desktop app and VS Code; it now only applies to unattended sessions. Second, three separate fixes close blind spots around dangerous shell commands: an rm that slipped past the guardrail when wrapped in a script, permission hooks that let an action through instead of blocking it when they failed to evaluate, and a BASHPID assignment that ran without asking. Over seventy entries in total, mostly reliability and interface work. Everything else is summarized in the roundup below.

Background commands no longer have a time limit locally

An earlier digest in this series noted the arrival of a time limit on background Bash and PowerShell commands: thirty minutes by default, two hours at most, after which Claude Code stops them and tells Claude. 2.1.288 revisits that limit's scope. The changelog is direct: "Changed the background command time limit to apply only in unattended sessions (-p, Agent SDK, CI, cloud); terminal, desktop app and VS Code sessions have no limit".

In practice, if you run Claude Code in a terminal, the desktop app or VS Code, a command you push to the background with run_in_background or the equivalent can now run as long as it needs, with no automatic cutoff. The limit only applies to sessions running unattended: claude -p, the Agent SDK, a CI job, or a cloud session. The agent view doc covers a different background mechanism, shell jobs started with claude --bg --exec or the ! prefix from the agents view, and says nothing about this split between attended and unattended sessions as of this digest: the changelog is ahead of it. If you run long builds or test suites from your terminal that take more than half an hour, you no longer need to work around the old limit. If you automate Claude Code in CI or in the cloud, nothing changes: the limit is still there, useful for keeping a forgotten job from running forever on a machine nobody is watching.

Three shell blind spots closed

The thread this digest has followed for several weeks continues: guardrails that already existed, but that one specific shape of shell command managed to dodge.

The first is about file deletion. The doc on critical paths states the principle in absolute terms: "Claude Code never lets a permissions.allow rule or a PreToolUse hook that returns 'allow' approve an rm or rmdir command that targets a critical path", such as the filesystem root or your home directory, and specifies that this circuit breaker holds even in modes that skip other prompts. The 2.1.288 changelog describes what still slipped through that net: a dangerous rm command, run inside a script passed to bash -c or sh -c, executed without the expected confirmation prompt in bypassPermissions mode or under a shell allow rule. Wrapping it in a script was enough to hide the command from the detector. This isn't a new hole in the principle, the doc already states it as absolute, it's the implementation that missed one specific shape of wrapping.

The second concerns permission hooks. The hooks doc explains the normal behavior: if a hook's matcher doesn't match the tool being called, the hook is simply skipped and the action proceeds as usual. That's intentional, and it still holds. What 2.1.288 fixes is different: when the matcher genuinely failed to evaluate, say an error during the comparison, or when the tool's input couldn't be serialized to JSON to hand to the hook, Claude Code treated that the same way as a skipped hook, letting the action through. Now, a PreToolUse or PermissionRequest hook that fails to evaluate blocks the action instead of letting it go. The distinction is subtle but real: a hook that doesn't match was never meant to block, a hook that crashes while trying to evaluate has no reason to behave the same way.

The third is quieter: the Bash tool's permission check let through, with no prompt, a BASHPID assignment whose value the shell evaluates as an arithmetic expression, a syntax detail easy to miss just reading the command. It now triggers a confirmation prompt.

Everything else, briefly

• /code-review --max-findings <n>|all: sets how many findings a review reports; the choice sticks until you pass --max-findings default again.
• Recoverable prompt after Ctrl+C: pressing Up on an empty prompt brings the cleared draft back, including pasted text and images.
• Ctrl+F filter in the agents view to find a session by name, and Alt+↑/↓ to jump between groups; both are rebindable in keybindings.json.
• "Prompt is too long": long conversations sometimes failed with this error instead of auto-compacting when the last reply reported zero token usage. Fixed.
• Mid-response API timeouts: non-interactive sessions and subagents now continue from the partial response instead of failing the whole turn.
• --resume: fixes cases where files or context restored by a compaction were dropped on resume, and where a turn's last response wasn't saved, leaving --resume showing an unanswered prompt.
• claude project purge becomes claude purge; the old name still works and prints a notice.
• New re-authenticate prompt when an MCP server asks for a wider OAuth scope mid tool call.
• Built-in gh api for cloud sessions whose image lacks the GitHub CLI.
• Path-scoped .claude/rules and nested CLAUDE.md files now also load when Write or Edit creates or changes a file in their scope, not only on Read.

The takeaway

If you run long commands in the background from a terminal, the desktop app or VS Code, the automatic thirty-minute cutoff is gone; it now only targets unattended sessions. For everything else, this release continues a project already under way rather than opening a new one: closing, one at a time, the specific spots where a shell command or a permission hook behaved differently than intended. None of these three fixes is dramatic on its own, but the series adds up to real hardening, not a coincidence of versioning.