[FEATURE] Feature request draft: agent-proof settings for cloud environments

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

On my Mac I protect my repositories from destructive git operations with a PreToolUse hook in managed settings (/Library/Application Support/ClaudeCode/). The hook blocks git push --force, --delete, +refspec, gh api ref mutations, and similar commands. Because the directory is root-owned and the agent runs as my user, the agent cannot edit or disable it. It is a deterministic guardrail, not a prompt-level rule.
Cloud sessions (Claude Code on the web) have no equivalent:

• Environment settings let me configure network access, a setup script and secrets, but not settings for Claude Code itself.
• The repository's .claude/settings.json can carry the same hook, but it is a project file the agent can edit, remove, or push changes to.
• A setup script could write /etc/claude-code/managed-settings.json, but the agent runs as root in the container, so that file is just as editable.

So the only guardrail available in the cloud is one the agent can switch off. My private repos are on the GitHub Free plan, which has no branch protection or rulesets, so nothing on the server stops a force push either. When I have asked a cloud session to force-push to main, nothing stopped it; locally the managed hook would have.

Proposed Solution

Let the environment owner set managed settings for a cloud environment, at least hooks and permissions.deny, in the environment configuration UI or API. They would apply to every session started in that environment, at managed precedence, and the agent could not modify them:

• the settings are delivered from outside the container (or into a location the agent's process cannot write), not from the checked-out repository
• disableAllHooks in user or project settings cannot turn them off, matching managed settings on desktop
• hook scripts referenced by these settings are stored with the environment configuration, so the agent cannot rewrite the script either
• sessions show which managed settings are in effect (e.g. in /status), so users can confirm the guardrail is active

Alternative Solutions

• Git proxy policy. Cloud sessions already route git through a credential-injecting proxy, and it already refuses branch deletion (https://github.com/anthropics/claude-code/issues/99384). An environment option to refuse force pushes and ref deletions at the proxy would be enforced no matter what command form the agent uses (scripts, aliases, other tools), which no client-side hook can guarantee. This would be an excellent complement, or a narrower first step.
• Project .claude/settings.json hooks (what I use today): work in a single-repo session, but are editable by the agent and reportedly ignored in multi-repo sessions (https://github.com/anthropics/claude-code/issues/89215).
• GitHub rulesets: the real server-side fix, but they require GitHub Pro for private repos on personal accounts.
• Off-GitHub backups (mirror + daily git bundle): recovery, not prevention.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. I create a cloud environment and, in its settings, add a managed PreToolUse hook that blocks force pushes and ref deletions.
2. I start a session in that environment and ask Claude to clean up a messy branch history.
3. Claude tries git push --force origin main; the managed hook blocks it and tells Claude to ask me to run it myself.
4. Claude cannot edit the hook or settings, because they live outside the container's writable state, so the protection holds even if a prompt injection or a misread instruction tells it to remove the guardrail.

Additional Context

• https://github.com/anthropics/claude-code/issues/99384 : the cloud proxy blocks branch deletion but allows force pushes, including to the default branch; it shows the proxy already filters some git operations.
• https://github.com/anthropics/claude-code/issues/89215 : a repository's .claude/settings.json is not loaded in (multi-repo) cloud sessions, so project-level hooks are not a reliable substitute.
• https://github.com/anthropics/claude-code/issues/98376 : hooks in /etc/claude-code/managed-settings.json reported ignored on Linux; the reporter makes the same point that managed settings are the only tamper-resistant place for hooks.