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.221 Home All releases ←olderv2.1.220 v2.1.222newer→
Claude Code v2.1.221

PR review artifacts can carry an "Approve on GitHub" button

Not switched on
Useful4 Signal5
Artifacts Notable not in their notes

PR review artifact pages can show a pinned button that approves the pull request from your GitHub account.

An approve-on-GitHub control for PR review artifacts is present behind CLAUDE_CODE_ARTIFACT, off by default.

Feature flag
tengu_cobalt_plinth On for this account, and not off by default

The flag server returned on for the one account this site reads, and nothing in this release compiles it off by default. The compiled default is shown below, and says which it is when we cannot read one: a fifth of gates compile in a string or a number rather than on or off, and most published releases have no gate table behind them at all. No client can see what the server returns for your account.

This account: on · anonymous baseline: on · compiled default in v2.1.221: on

These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.

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

CLAUDE_CODE_ARTIFACTenableArtifact
What

The artifact-pr-review skill and template gained a third capability alongside the live staleness binding and decision pills: a pinned control that submits an approving GitHub review as the viewer.

Details
  • adds a stamp payload field, a prr-stamp JSON island, and a pinned approve script
  • when filled, the page shows a fixed control whose disclosure says it posts from the viewer's own account, after a click-time re-read confirms the head SHA still matches the anchor
  • the script arms only if the read and write tools live on one connector whose display name matches /github/i, the read declares readOnlyHint: true, the write does not, the write's name matches a positive create-and-submit-review allowlist, and every input value is one of the anchor's own identifiers or an approve word
  • the raw (non-composed) publish lane always keeps {"stamp":null}
  • gated on artifact availability (env CLAUDE_CODE_ARTIFACT / gate tengu_cobalt_plinth, in-source fallback false, plus plan tier and the enableArtifact setting); within that, the control exists only when the model fills stamp and publish validation accepts it
Evidence

Posts an approving review of <code class="stamp-target"></code> from your own GitHub account, as you, if the branch is unchanged.

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.221 →