Claude Code 2.1.290-291: Chrome, pyright, and permissions get tighter

2.1.290 of Claude Code, released October 5, 2026, is a catch-all release: over a hundred and fifty entries, mostly targeted fixes to specific surfaces: mods and plugins, the agents view, /ultrareview, the Claude apps gateway, VS Code, Slack. In the middle of that, a handful of changes actually touch daily use: Chrome and pyright change their default behavior, WebFetch stops silently truncating pages, scheduled tasks survive compaction better, and several permission gaps close, continuing a thread this digest has followed for weeks. 2.1.291, released the next day, exists only to fix two regressions, one introduced by 2.1.290 itself and the other by 2.1.288. The first one touched the reliability of permission-prompt answers in cloud sessions.

Chrome and pyright: two defaults that change

Two changes in 2.1.290 don't fix a bug, they move a default. Claude in Chrome shares your browser's login state with Claude, which means access to any site you're already signed into. Until now, a project's settings file could turn that integration on by itself. The changelog is direct: "Changed Claude in Chrome so that a project's settings files can no longer turn it on; use --chrome, /chrome or your user settings." A shared or cloned repository can no longer decide, on your behalf, that Claude gets to open your browser and act inside your logged-in sessions: it now takes the --chrome flag, the /chrome command, or a setting you configure yourself in your own user settings.

The second concerns pyright, the Python type checker. The permissions doc describes a built-in set of commands recognized as read-only that run without a prompt in every mode, including ls, cat, grep, and read-only forms of git, and notes that the set isn't configurable. Until now, Claude Code counted pyright among them and ran it without asking. 2.1.290 takes it off that list: "Changed the Bash tool to ask for permission before running pyright, which is no longer treated as a read-only command." If Claude runs pyright to check its work in a Manual mode session, expect a confirmation prompt you didn't get before, unless you add an allow rule for it.

WebFetch stops staying quiet, so do scheduled tasks

Two fixes in 2.1.290 share the same idea: a silent failure becomes a visible one, or stops happening at all. I ran into the first one while researching this very article. The tools reference still says today that "Large pages are truncated to a fixed character limit before processing," without saying what happens to the cut text. Fetching the official changelog for this digest, WebFetch handed back a page nearly a million characters long: only the first hundred thousand were read, with an explicit warning about what was missing and an offset parameter to pick the reading back up exactly where it stopped. That's exactly what 2.1.290 fixes: before this, the text past the limit just vanished without a word.

The second touches fixed-interval /loop runs and scheduled reminders. The scheduled tasks doc explains that these tasks get restored automatically when you resume a session with --resume or --continue, as long as they haven't expired. The 2.1.290 changelog fixes a case where that promise didn't hold: a scheduled task silently failed to come back when you resumed a conversation that had been compacted (the fix covers compactions made from this version on), and a recurring one could fire an extra time on every resume, respawn, or fork. If you run a long-lived /loop, this fix matters directly: a loop that stops without a message is the worst kind of failure, the kind you only notice once the backlog has already piled up.

The permissions work continues

The thread this digest has followed for weeks continues in 2.1.290: guardrails that already existed, which a precise form of command or path still managed to slip past.

The first concerns plan mode. The permission modes doc lists connector tools an organization has set to ask among the actions no mode auto-approves: "Connector tools your organization set to ask, in sessions where that setting reaches Claude Code." The 2.1.290 changelog fixes a case where auto mode's classifier approved a non-read-only connector tool under that server-pushed ask rule anyway, while it was running in plan mode. The rule existed on the organization's side, it just didn't hold in that specific mode.

The second touches the rule files themselves. The permissions doc sets out the principle for symlinks: "Deny rules: apply when either the requested path or the file it resolves to matches. A symlink that points to a denied file is itself denied." 2.1.290 extends that coverage to a case that still slipped through: a project CLAUDE.md, rule file, or AGENTS.md that was actually a symlink to a file outside the working directories still loaded, ignoring permissions.blockReadsOutsideWorkingDirectories and any Read deny rule.

Another batch touches how shell commands get recognized: a deny or ask rule missed a command or path whose name came from a variable set as a prefix on declare, typeset, export, or readonly; some commands whose variable names zsh reads differently from bash got auto-approved, as did read-only commands (rg, git grep) whose arguments the shell would still expand as wildcards; and the short form of a git clone option kept the sandbox exemption of a pattern like git * in sandbox.excludedCommands. Same story for URL allow and deny patterns with a wildcard inside a punycode-encoded host label (xn--), which matched differently from one process to the next. Broader still: some permission rules and safety checks weren't applied to a tool call after a PreToolUse hook rewrote its input. In every case, the rule targeted the right command or domain, it just didn't recognize it under that specific disguise.

Everything else, briefly

• WebSearch budget: moves from a flat 200-call session limit to a budget that refills over time, 100 per hour by default, tunable with CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR.
• claude attach and claude logs: part of a session's name is now enough, no need for the full ID anymore.
• /teleport: now refuses to stash when that stash would delete files in a folder that had replaced a git-tracked file of the same name, and says why.
• Sessions with hundreds of images: no longer get stuck on a rejected-request error.
• API content filter: a response cut off mid-thought by the content filter is now retried once before an error shows.
• Resumed subagents and teammates: no longer lose their earlier thinking and prompt cache after receiving a message mid-run.
• /rewind: now lists a prompt sent while Claude was still working.
• 2.1.291: fixes two regressions from recent versions the next day, one where cloud sessions could drop the answer given to a permission prompt, the other where a session's last messages could be lost on quitting.
• VS Code, Claude Tag in Slack, cloud sessions, and Code Review get their share of 2.1.290 too: mostly display and reliability fixes specific to those surfaces.

What to take away

If you enable Claude in Chrome from a project settings file, that no longer works: use --chrome, /chrome, or your own user settings instead. If Claude runs pyright in your sessions, expect the confirmation prompt that now comes with it, or add an allow rule. If you rely on a /loop or a scheduled reminder in a long-running session, this version fixes exactly the kind of silent failure that only shows up once the backlog has piled up. Beyond that, 2.1.290 extends a project already underway rather than starting a new one: closing, one at a time, the exact spots where a permission rule existed on paper without holding in practice. None of these fixes is dramatic on its own, but the series adds up to something real.