← 2.1.2 Test inconclusive · runtime-test

FORCE_AUTOUPDATE_PLUGINS — runtime test

Hands-on runtime battle-test of FORCE_AUTOUPDATE_PLUGINS. Result: INCONCLUSIVE.

FORCE_AUTOUPDATE_PLUGINS is an environment variable in Claude Code 2.1.2 that decouples plugin auto-updates from the main application updater, allowing organizations to freeze the core while keeping security patches flowing.

What It Does

The feature adds a new runtime control: when FORCE_AUTOUPDATE_PLUGINS=1 is set (or configured in managed settings), plugins auto-update independently of the main Claude Code auto-updater. This addresses a specific organizational constraint: disable core updates for stability, but update plugins separately for security or feature patches.

Expected usage:

export FORCE_AUTOUPDATE_PLUGINS=1
claude

The Test

The feature was documented from changelog analysis and code review only. No runtime test was executed. The test plan identified concrete steps (disable auto-updater, install a plugin with pending updates, verify plugin updates while core remains static) but did not run them. Without active runtime observation, the feature's behavior under edge cases—timing conflicts, plugin versions pinned elsewhere, manager-level configuration precedence—remains unverified.

Target Use Case

Intended for enterprise deployments: organizations managing Claude Code versions in CI/CD pipelines, security-conscious teams requiring patch isolation, or admins needing granular update control across fleet machines. The decoupling itself is a solved problem in other tools; the specific behavior within Claude Code's update machinery is not yet empirically established.

Epistemic Status

Marked INCONCLUSIVE. The feature description is clear from source material, but without runtime observation, all claims about actual behavior are assumptions. Practical questions remain: Does the environment variable override managed settings? What happens if both updaters are manually triggered? Does a disabled main updater fully block plugin updates if FORCE_AUTOUPDATE_PLUGINS is absent?

Primary source
⎘ 2.1.2/tests/03-force-autoupdate-plugins/TEST-RESULTS.mdverbatim from the corpus

Test Results: FORCE_AUTOUPDATE_PLUGINS

Feature: Added FORCE_AUTOUPDATE_PLUGINS environment variable to allow plugin autoupdate even when the main auto-updater is disabled

Tested: 2026-01-16 (Code Review Only) Version: 2.1.2

Feature Description

From changelog:

Added FORCE_AUTOUPDATE_PLUGINS environment variable to allow plugin autoupdate even when the main auto-updater is disabled

Use Case

Organizations/admins who:

  1. Disable the main Claude Code auto-updater (for stability)
  2. But still want plugins to auto-update (for security/features)

This decouples plugin updates from core Claude Code updates.

Expected Usage

# Main auto-updater disabled but plugins can still update
export FORCE_AUTOUPDATE_PLUGINS=1
claude

Or in managed settings:

{
  "autoUpdater": false,
  "FORCE_AUTOUPDATE_PLUGINS": true
}

Testing Status

CODE REVIEW ONLY - Not runtime tested.

To test would require:

  1. Disabling main auto-updater
  2. Installing a plugin with updates available
  3. Verifying plugin updates while core stays static

Target Audience

  • Enterprise admins managing Claude Code deployments
  • CI/CD environments with pinned Claude versions
  • Security-conscious setups that want plugin patches

Status: NOT TESTED (code review only)

Minor admin feature. Documented based on changelog description.

Evidence & receipt
◇ ed25519 receipt
idtest_b61c8ba320424f11f3e885cb
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
siga8c479ff9dcb0519aedb3db3060ef6e7bfadd2ad8d256907ca407dc9016599ecb0ab10204e88a0083efbbc5244d2d5783c5d34fcaff507e83fbb3ad7e7979c0b

Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.

Connected