[BUG] Sideload-flag rejection happens before server-managed settings refresh — machines stay stuck on a stale policy the admin already rolled back

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (#80763 covers disableSideloadFlags breaking Desktop Local Sessions; this report is about the recovery path being impossible after the admin rolls the flag back)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When disableSideloadFlags is delivered via server-managed settings (claude.ai Admin Settings → Claude Code, Team plan) and later removed by the admin, machines that cached the old policy never pick up the rollback if their only Claude Code launches carry a sideload flag.

Order of operations at startup appears to be:

1. CLI validates argv against the cached policy in ~/.claude/remote-settings.json
2. --plugin-dir present + cached disableSideloadFlags: true → exit code 1
3. The remote-settings refetch that would replace the cache with the corrected policy never runs on this path

The Claude Desktop app always spawns the CLI with --plugin-dir (bundled integrations + locally installed plugins — see #80763), so an affected desktop-app user is in a permanent crash loop the org admin cannot remotely undo: the server policy is fixed, but every launch fails against the stale cache and never refreshes it.

Reproduction

1. Org deploys server-managed settings containing "disableSideloadFlags": true; client fetches and caches it in ~/.claude/remote-settings.json
2. Admin removes the key in the console (verified served: a plain claude run on another machine fetches the corrected policy)
3. On the affected machine run claude --plugin-dir ./x -p "hi" → rejected with "--plugin-dir is disabled by your organization's managed settings (disableSideloadFlags)"
4. Inspect ~/.claude/remote-settings.json → still contains disableSideloadFlags: true; repeat step 3 any number of times — never recovers
5. Run plain claude -p "hi" once → cache refreshes to the corrected policy → step 3 now succeeds

Also reproducible by hand-editing disableSideloadFlags: true into the cache file: the failed flagged run leaves the edit in place; a plain run replaces it.

Expected Behavior

Either refresh (or attempt to refresh) server-managed settings before enforcing sideload-flag policy, or treat a flag rejection as a trigger to refetch so the next launch sees the current policy. Without one of these, any org that ever ships disableSideloadFlags risks stranding its desktop-app users with no remote remediation.

Workarounds (for anyone else hitting this)

• rm ~/.claude/remote-settings.json, then relaunch (cache re-downloads on next successful start), or
• run plain claude once in a terminal and exit

Environment

• Claude Code 2.1.224, macOS (Darwin 25.x)
• Policy delivered via claude.ai server-managed settings (Team plan), org OAuth login
• Desktop app + CLI both affected; desktop app has no flag-free launch path so it never self-heals