If managed settings need consent and nothing can prompt you, it's deferred to your next interactive session.
What's wrong with this entry?
When remote managed settings need your consent but the current command cannot display a prompt, Claude Code now logs that the prompt is deferred to the next interactive session rather than reporting only that no consent surface exists. Either way it keeps running on the settings you last consented to, and the fetch is marked unsuccessful.
- The older message,
No consent surface in this interactive session, is still the fallback. - Which of the two paths runs is decided by a runtime check in the command itself, not by any settings key.
Remote settings: Consent prompt deferred to the next interactive session (this command cannot host it); keeping the consented baseline
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.236
Managed-settings review prompt dropped from the main UI
Both mention managed
-
v2.1.242
Startup can wait on a remote managed-settings refresh, with a deadline
Both mention managed
-
v2.1.248
Telemetry on how OS-level managed settings are read
Both mention managed