Source Intelligence
Follow Discord

DisclaimerUnofficial, and not affiliated with Anthropic. Nearly all of this is read straight out of what ships: npm bundles, captured prompts, published docs. Anthropic's own notes go in verbatim, marked as theirs. The rest is my reading, and every entry carries the strings behind it. If one looks wrong, vote it down and say why.

← All of v2.1.235 Home All releases ←olderv2.1.234 v2.1.236newer→
Claude Code v2.1.235

Conversations pin an atis client-config value and persist it in the transcript

Under the hood
Useful2 Signal4
Client Config

A client-config value is now pinned for a whole conversation and saved in the transcript, surviving fork and resume.

Feature flag
tengu_kestrel_moor Not enough to say

Nothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.

This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.235: off

Read once, for one account on one subscription tier, against v2.1.235. It isn't a statement about your account. What a flag value here can and cannot tell you

What

The client-config value named atis is now latched once per conversation and preferred over the live config for the remainder of it, so a config change mid-session cannot shift behaviour partway through. The pinned value is recorded in the session state file and in the session transcript, and it survives fork, resume and relocation of a session.

Details
  • Gated by tengu_kestrel_moor, which falls back to on; with the gate off, the live client-config value is read on each use instead of the pinned one.
  • Held on the conversation next to the sticky beta flags and the per-turn effort pins, and merged using the same "always" and "last-wins" rules as the existing isolation latch.
  • Carried through fork and resume, and readable through the session-state snapshot APIs.
  • Written to the transcript as an entry of the form { type: "atis-latch", atis: <value>, sessionId: <id> } whenever the pinned value changes, and re-emitted when a session is forked or moved to a new location.
  • The transcript write itself has no gate found on it and happens wherever transcripts are written, including when the latch feature is otherwise off.
  • On read, the entry is accepted only if its recorded session id matches the file being read and the value is printable ASCII, so a transcript copied from elsewhere cannot inject a pinned value.
Evidence

atis-latch, { type: "atis-latch", atis: g, sessionId: f },

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.

See this entry in the whole of v2.1.235 →