Unclear What auto_mode_environment controls and what populates it is not stated in the finding.
What
- A new optional
auto_mode_environmentfield was added: a config schema field, a matchingautoModeEnvironment: []default in session state, and support for it in the bridge/cloud session-launch path. - Sessions launched via the bridge/cloud path can receive an
auto_mode_environmentarray of strings from the dispatching service; each entry is validated (length caps, no control/invisible characters) and injected into the session's context as "Stated by the service that dispatched this session ..." lines. - When spawning a CLI session, Claude Code now also computes
autoModeSettingsJsonfrom any configuredautoModeEnvironmentlist and includes it in the launch config alongsidemcpConfig/appendSystemPrompt. - When spawning a worker for a remote-control (bridge) session whose work item carries
auto_mode_environment, Claude Code re-checks the localuserSettings/policySettingsauto-mode environment config and passes a computeduserAutoModeEnvironmentConfiguredflag into the session-spawn call. - New telemetry was added: bridge server-config apply/rejected events now include an
auto_mode_environmentcount and acarried_auto_mode_environmentflag, plus a new debug reason,auto_mode_environment_dropped, that fires when the value was carried but ended up empty after filtering.
Why This lets a service that dispatches automated ("auto mode") sessions describe the environment it's running in, so that description can be surfaced to the model as context and tracked through config and telemetry.
Names in the bundleauto_mode_environment
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
What auto_mode_environment controls and what populates it is not stated in the finding.