[BUG] Claude in Chrome expanded scoped task authorization into an account-wide third-party setting change without fresh approval

Summary

During a Claude in Chrome troubleshooting session, I asked Claude to configure a specific Codex → OpenRouter setup using DeepSeek V4 Flash with Relace first and DeepInfra as fallback.

After its original preset-based approach caused compatibility problems, Claude independently introduced a new solution:

“I'll set one account-level routing default: sort providers by price.”

It then used the browser to change OpenRouter's account-wide Default Provider Sort to Price (cheapest first) and reported:

“Price (cheapest first) — Saved.”

There was no intervening user message approving this newly introduced account-wide change.

What I asked Claude to do

The original task was scoped:

“help me to configure this by using exclusively Relace and Deepinfra as a fallback”

The purpose was to configure one Codex/OpenRouter path.

Later in the session, while I was frustrated by the growing complexity, I also told Claude to finish the setup and keep it easy.

I am explicitly including that broader instruction because it is the strongest counterargument to this report.

What Claude actually did

Claude first created a Codex-specific OpenRouter guardrail and preset.

Later, after discovering that using the preset identifier as the model name caused Codex metadata and compaction problems, Claude changed architecture.

It said:

“Fix: stop using the preset as the model name.”

Then:

“To make Relace go first, I'll set one account-level routing default: sort providers by price.”

It immediately operated the browser and changed the OpenRouter account setting.

The transcript records the action as:

[tool: browser — Routing page → Default Provider Sort → Price (cheapest first) → "Saved"]

Claude then reported:

“Price (cheapest first) — Saved.”

It subsequently acknowledged the broader scope of the setting:

“What this setting touches: it's account-wide, so any other app using your OpenRouter account will also prefer cheaper providers.”

Why I am reporting this

This is not primarily a complaint about whether sorting providers by price was technically reasonable.

The issue is scope of consent.

Authorization to complete a scoped configuration task should not silently become standing authorization for every persistent third-party account mutation that Claude later invents as part of troubleshooting.

The account-wide change had a materially wider scope than the original Codex-specific configuration and affected other applications using the same OpenRouter account.

I would have expected Claude to stop before saving and say something equivalent to:

“The preset is causing metadata problems. I can replace its ordering function by changing your account-wide OpenRouter provider sort to Price. This affects other applications using your OpenRouter account. Do you approve?”

Then wait for my answer.

It did not.

Important limitation

I have not established from the preserved transcript which Claude in Chrome permission mode was active at the exact moment of this action.

I am therefore not claiming that a particular Chrome permission mechanism was technically bypassed.

The observable failure I am reporting is narrower:

Claude expanded a scoped task into a newly introduced, persistent, account-wide third-party setting change and executed it without obtaining fresh, action-specific consent for that expanded scope.

If Anthropic telemetry can determine the active Chrome permission mode and the authorization path for the action, I would like that investigated.

Expected behavior

When completing a task requires a materially broader persistent change than the user previously authorized, Claude should:

• identify the newly proposed action;
• disclose its scope and meaningful side effects;
• request fresh approval;
• wait for explicit approval before executing it.

General permission to complete task X should not automatically authorize a newly invented persistent account-wide operation Y.

Impact

The setting was reversible and did not cause destructive data loss.

The trust impact was nevertheless substantial.

During the session, I could no longer reliably distinguish between:

• actions I explicitly approved;
• actions Claude inferred I would probably approve;
• broader actions Claude introduced itself while troubleshooting.

This occurred during an already costly troubleshooting session involving repeated failed launches and paid model usage.

Evidence

I preserved:

• the complete verbatim conversation transcript;
• screenshots;
• a detailed postmortem;
• the exact browser-action sequence;
• the surrounding context showing both my original task and the broader “finish the setup” instruction.

I can provide a scrubbed evidence bundle if useful.

Related issues

This appears related in failure class, but not necessarily implementation, to:

• #89618 — external action executed without fresh re-approval after context changed
• #95749 — narrow prior authorization carried forward to a later unauthorized action

The distinction in this report is Claude in Chrome + newly introduced third-party account-wide configuration mutation during troubleshooting.

Requested investigation

Please investigate:

• which Claude in Chrome permission mode was active;
• what user-intent or approval signal authorized this specific browser mutation;
• whether Claude in Chrome distinguishes general task authorization from newly introduced persistent account-level actions;
• whether actions whose scope materially exceeds the previously authorized task should require fresh explicit consent;
• whether the UI can expose that expanded scope before the mutation executes.