[guide] docs: document the Claude Remote Control pin-off (#5607) — CHANGELOG v4.1.0 Security + security-model.md Layer 4

[kubestellar-hive]

Documentation Fix

Documents the Claude Remote Control pin-off (#5607, PR #5619, commit e26a861, shipped in v4.1.0), which previously appeared nowhere in the docs (grep -rni "remote control" src/docs docs CHANGELOG.md returned nothing).

Files/cluster claimed: CHANGELOG.md (v4.1.0 ### Security section only) and src/docs/security-model.md (Layer 4 — agent sandboxing, one new bullet). Disjoint from open PRs #5559 (UPGRADE.md), #5625 (pkg/convergence code), #4032 (proxy code).

Changes:

• CHANGELOG.md — new Security entry under 2026-09-02 (v4.1.0): the bridge auto-start via server-side rollout flag since Claude Code ~2.1.226, the fleet-wide exposure of --dangerously-skip-permissions sessions under the shared claude.ai account, the add-if-missing remoteControlAtStartup: false pin, the operator opt-out (true in /data/home/.claude/settings.json, never clobbered, Info receipt), and the hasUsedRemoteControl launch-time warning.
• src/docs/security-model.md — new Layer 4 bullet documenting the same mechanism alongside the other per-agent launch controls.

Fixes #5627

---

Filed by guide agent (ACMM L5 — hold-gated mode). Hold-gated: human review required.

— hive: agent=guide backend=copilot model=claude-sonnet-4-6

[clubanderson]

Reviewed. Approve. 54 checks, zero failures.

I checked this more carefully than a docs PR would normally warrant, because it documents a security change that already shipped — and the content is right where it matters most.

The never-clobber semantics are stated correctly. The merge is add-if-missing only; an operator who wants the bridge sets remoteControlAtStartup: true in the same file and hive never overrides it. Getting this wrong in either direction would be worse than no documentation — an operator would either believe they had opted out when they had not, or believe hive would override a choice it actually respects.

It explains the mechanism, not just the setting. The bridge auto-starts whenever no explicit value exists because the CLI falls through to a server-side rollout flag — which is why a routine image upgrade could flip it on fleet-wide with no local change, and why the in-pane toggle was not a fix (session-scoped, so every relaunch brought it back). A reader can now reason about their own exposure rather than just copy a setting.

It covers both delivery paths — the shared /data/home/.claude/settings.json for the plain claude backend, and the inference settings seed for gateway agents — and the hasUsedRemoteControl launch-time warning. The Info receipt on an operator-enabled bridge is the right touch: an enabled bridge stays explainable rather than looking like the bug returning.

One correction to something I said on #5627: I flagged the #5607 citation as a dead reference. That was my error — I queried the pulls endpoint, which 404s for an issue number. #5607 is the issue, #5619 is the PR, and citing the issue in a CHANGELOG entry is the right call. No change needed here.

The security-model.md entry sits correctly in Layer 4 alongside the other agent-isolation controls, and reads consistently with its neighbours.

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

Thank you for your contribution! Your PR has been merged.

Check out what's new:

• KubeStellar Console — Live multi-cluster dashboard
• Marketplace — Community extensions
• Knowledge Base — Troubleshooting and how-tos

Stay connected: Slack #kubestellar-dev | Multi-Cluster Survey