[Sonnet 5] Inconsistent refusal of "system/security settings" changes within the same session

Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude refused a reasonable request

What You Asked Claude to Do

aI asked Claude to type a short command (or, alternatively, just write the text into Notepad without executing it) on a remote Windows 365 Cloud PC that I administer, to remove a registry-based Microsoft Edge policy (BrowserSignin) via PowerShell:

Remove-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Microsoft\Edge" -Name "BrowserSignin"

I explicitly stated I am the sysadmin (fi.admin@) and authorized the action, and offered to press Enter myself so Claude would only be typing the text.

What Claude Actually Did

Claude refused, citing the "Modifying system or security settings" prohibited category, even with explicit authorization.
When I asked Claude to instead just type the same text into Notepad (no execution at all, just writing text to a scratch file), Claude Code's own automatic permission classifier blocked the action independently, tagged "Security Weaken."
Earlier in the SAME session, Claude directly created/modified an Azure NSG rule opening a new inbound port (30080) to the public internet on a VM, and installed/configured software (k3s, systemd services, networking) on Linux VMs, without any hesitation or extra confirmation.
Claude acknowledged during the conversation that it does not have a fully consistent, gapless rule distinguishing these cases, and that the practical boundary partly rests on the independent classifier's decision rather than a clean derivable principle.
Note: Claude did provide the exact command text as information for me to type myself, and gave a shortened version to reduce typing effort — it only declined to be the one entering it into the system.

Expected Behavior

Either Claude should apply the same standard it used for the Azure NSG/software-installation actions (perform the action directly when the user, confirmed as the resource's administrator, explicitly authorizes it), or it should clearly document up front that "system/security settings" specifically excludes remote infrastructure/DevOps configuration the user directs (VMs, NSGs, software installs), so the boundary is predictable rather than discovered through trial and error mid-session.

Files Affected

N/A — no files or registry keys were actually modified, since Claude declined before any change was made. The only file involved was a scratch text file (Notepad) that Claude also declined to write to.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

Ask Claude, mid-DevOps-session, to perform a routine cloud infra action (e.g. open a firewall port, install software on a VM) — Claude does it directly.
Ask Claude to type/remove a local registry value on a Windows machine you administer, even after explicitly stating you are the admin and authorizing it — Claude refuses, citing "Modifying system or security settings."
Ask Claude to just write the same text into Notepad (no execution) — the request is blocked by Claude Code's own automatic permission classifier as well.

Claude Model

Sonnet

Relevant Conversation

Claude: "No, I won't do this either, not even on the sysadmin's request — this isn't up for negotiation."
Claude (explaining why typing counts as performing the action, even if the user presses Enter): "For me, the typing itself counts as performing the action, not just pressing Enter."
Claude, after the Notepad-only attempt was blocked by Claude Code's own tooling: "The system itself stopped this step — an automatic security filter (tagged 'Security Weaken') refused the action."

Impact

Low - Minor inconvenience

Claude Code Version

Not checked during session (Claude Code desktop app / Chrome-controlled browser session)

Platform

Anthropic API

Additional Context

This surfaced in a long, single DevOps session that also involved provisioning Azure VMs, opening NSG rules, and installing/configuring a Kubernetes (k3s) cluster on Linux VMs — all performed directly by Claude without extra confirmation. The inconsistency became apparent specifically when the target shifted from "infrastructure we created from scratch this session" to "an existing, already-configured Windows setting on a company-managed device." A written summary of the full back-and-forth (in Hungarian) is available if useful for reproducing the context.

No implementation file or test is identified in the report. Start by reproducing the approved Azure/DevOps actions and the refused Windows registry and Notepad requests, then trace the policy and automatic permission-classifier decisions; done means the boundary is applied consistently or documented clearly.