# Claude Code v2.1.272

> Claude Code v2.1.272, released 14 Sep 2026 (2026-09-14). 18 entries read out of the shipped bundle. Unofficial, and not affiliated with Anthropic.

Web version: https://changelogs.core-directive.com/v/2.1.272

This build adds a new AppifactRepl tool that runs a full JavaScript program against an Artifact's data in one shot instead of one call at a time, including a claude.see() helper that lets scripts attach up to 4 images and text notes to a tool result, and an artifact_call protocol so scripts can issue actions like get, set, upload, and publish. None of it is reachable yet: it only activates for the remote_cowork entry point behind the tengu_buzzing_lightning flag, its master switch lives outside this bundle, it only runs unsandboxed, and it does not work on Windows. Supporting plumbing also landed quietly, including a dedicated permission check for disabling the REPL tool and a routing hint that appears in Artifact read output only when the REPL tool is present, alongside a second feature-flagged tool referenced as isPewterOwlTool sitting next to the existing "Brief" tool.

Two things are usable today. A new MCP command called 'xaa' handles IDP login, and the Artifact quickstart gains a 'start kit' mode that saves type and design-system files to disk as a local scratchpad instead of reading them in one at a time.

This release also fixes a bug where bridge QR-code text output could be built from stale, unresolved data, correcting what got rendered in that display path.

## What probably matters to you

Anything you can use today, anything that visibly changes, and anything worth poking at. One line each, open for detail.

### AppifactRepl tool: a full JS-REPL tool for filling artifacts, wired in but gated off by an out-of-bundle check

AppifactRepl is fully built and wired in, but its on/off switch lives in code outside this bundle

**Unclear.** Whether `isAppifactReplToolEnabled()` defaults to true or false cannot be determined, since its code lives outside this bundle.

**What**

The `AppifactRepl` tool (see related entries above) is fully implemented: it has extensive built-in instructions, is registered in the tool list, spawns a child process running `node scripts/appifact_sdk.js --repl -`, scrubs its output for sandbox safety, and is wired into permission-rule matching, tool-name caching, and file-read tracking.

Every way of reaching the tool is guarded by a call to `isAppifactReplToolEnabled()`, but that function's actual logic lives in a separate chunk of code that is loaded dynamically at runtime and isn't included in this bundle, so it can't be determined from the shipped code whether the tool defaults to on or off.

**Why**

The tool is fully built and connected, but whether it's actually reachable depends on a switch that ships separately from the app itself.

- Area: Artifact REPL
- Tier: Nothing to try yet
- Useful: 5/5
- Signal: 5/5
- Present in the build but not switched on

### New AppifactRepl tool: run JavaScript against the Artifact SDK

A new AppifactRepl tool runs a full JavaScript program against an Artifact's data instead of one call at a time

**Unclear.** The `tengu_buzzing_lightning` gate that may control this tool has not been read for this account, so it's unclear whether or when it's active.

**What**

A new tool called `AppifactRepl` runs a Node.js REPL (a read-eval-print loop, a live JavaScript session) via `node scripts/appifact_sdk.js --repl -`. Instead of issuing one Artifact tool call per document, a script can run against an Artifact's whole document store at once, using `claude.use("db")`, `claude.use("files")`, and `claude.use("assets")` to reach the database, files, and assets respectively.

Scripts can also call `claude.see()` to attach images or text to the tool's result, and the tool can run a named skill's own SDK script instead of the built-in one.

**Why**

Running a whole script against an Artifact's data in one go, instead of one Artifact call per document, should make building or editing an Artifact's contents faster and less repetitive.

- Flag `tengu_buzzing_lightning`: Not enough to say (read for one account on one subscription tier against v2.1.272; this account: no value returned, anonymous baseline: no value returned, compiled default: not a boolean we can read) 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.
- Area: Artifact REPL
- Tier: Nothing to try yet
- Useful: 5/5
- Signal: 4/5
- Present in the build but not switched on

### New MCP 'xaa' IDP login command

A new MCP command, 'xaa', references an IDP login module

**Unclear.** It's unclear what the `xaa` command actually does or when it's exposed to users, since only the reference to the login module was found.

**What**

A new CLI command function is wired to a command named `xaa`, and it references a module for IDP (identity provider) login related to MCP (Model Context Protocol).

**Why**

This points to a new or upcoming way to log in to an MCP server through an identity provider, though the finding doesn't show what the command does when run.

- Area: MCP
- Tier: Use it now
- Useful: 4/5
- Signal: 4/5

### AppifactRepl gated behind remote_cowork entrypoint + tengu_buzzing_lightning flag

AppifactRepl only turns on for the remote_cowork entry point, gated behind the tengu_buzzing_lightning flag

**Unclear.** The `tengu_buzzing_lightning` gate has not been read for this account, so whether it is switched on here is unknown.

**What**

The AppifactRepl tool (see the related entry on this REPL) only becomes available when the `CLAUDE_CODE_ENTRYPOINT` environment value is `remote_cowork`, and even then only if a feature flag called `tengu_buzzing_lightning` is turned on for the account. This flag defaults to false unless a server enables it.

**Why**

This confirms AppifactRepl is being rolled out gradually and tied to a specific entry point into Claude Code, rather than being available everywhere at once.

- Flag `tengu_buzzing_lightning`: Not enough to say (read for one account on one subscription tier against v2.1.272; this account: no value returned, anonymous baseline: no value returned, compiled default: not a boolean we can read) 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.
- Area: Artifact REPL
- Tier: Nothing to try yet
- Useful: 3/5
- Signal: 4/5
- Present in the build but not switched on

### Quickstart 'start kit': saving Artifact type/design-system files to a local scratchpad

Artifact quickstart gains a 'start kit' mode that saves type and design-system files to disk instead of reading them one by one

**What**

The Artifact quickstart flow has a new "start kit" mode. Instead of the model reading an Artifact type's and design system's files through repeated Artifact tool calls, this mode saves those files to a local scratchpad directory on disk and tells the model to read them all at once with a single `tail -n +1` command in the Bash tool.

The mode enforces caps, refusing when there are "more than" a set number of files or when the total size goes "over the 8 MB total" limit.

**Why**

Reading a batch of files from disk in one Bash call is faster and cheaper than making many separate Artifact tool reads, speeding up the start of an Artifact quickstart.

- Area: Artifact Quickstart
- Tier: You'll notice
- Useful: 4/5
- Signal: 3/5

## Bug Fixes

### Bug fix: bridge/QR output split used stale variable

Fixed a bug where bridge QR-code text output could be built from stale, unresolved data

**What**

The routine that renders a bridge connection's QR code as text (using a UTF-8, low-error-correction QR encoder) was splitting the wrong variable into lines: it used the value captured before an asynchronous operation completed, instead of that operation's actual resolved result. This is now fixed.

**Why**

The previous behavior could have produced stale or empty QR-code text output instead of the correct, up-to-date code.

- Area: Elsewhere
- Tier: You'll notice
- Useful: 2/5
- Signal: 2/5

## In Development

### claude.see() lets REPL scripts attach images/text to the tool result

claude.see() lets AppifactRepl scripts attach up to 4 images and text notes to a tool result

**What**

Scripts running inside the new AppifactRepl tool (see related entries) can call `claude.see({text, images})` to attach images and text notes to the tool's result. Up to 4 images are allowed per result, and only PNG or JPEG images are accepted; anything larger or in another format is refused, with messages such as "at most 4 images per result" and "not a PNG or JPEG".

**Why**

This lets a REPL script show visual output, such as a rendered preview, directly alongside its result instead of only returning text.

- Area: Artifact REPL
- Tier: Nothing to try yet
- Useful: 3/5
- Signal: 3/5
- Present in the build but not switched on

### Second gated tool alongside "Brief": isPewterOwlTool

A second feature-flagged tool, referenced as isPewterOwlTool, sits alongside the existing Brief tool's flag

**Unclear.** The finding only shows a name reference; what `isPewterOwlTool` controls or what the tool does is not established.

**What**

The tool-name resolver now imports `isPewterOwlTool` from the same dynamically-loaded chunk that already supplies the Brief tool's name, the send-user-file tool's name, and the Brief tool's own enabled check (`isBriefEnabled`). This suggests a second tool, alongside Brief, that is controlled by its own feature flag.

**Why**

This points to another tool being prepared for gradual rollout in the same way the Brief tool was, though what this tool actually does isn't shown here.

- Area: Tool Gating
- Tier: Nothing to try yet
- Useful: 1/5
- Signal: 3/5
- Present in the build but not switched on

### REPL runs unsandboxed only, and is unsupported on Windows

AppifactRepl currently only runs unsandboxed and does not work on Windows

**What**

The process that starts an AppifactRepl session refuses to run on Windows. It also has no way to run inside a sandbox (an isolated execution environment) yet: it only runs commands unsandboxed, and if unsandboxed commands are disallowed for the session, it refuses to start at all.

**Why**

Anyone on Windows, or in a session where only sandboxed commands are permitted, won't be able to use AppifactRepl for now.

- Area: Artifact REPL
- Tier: Nothing to try yet
- Useful: 1/5
- Signal: 2/5
- Present in the build but not switched on

## Internal Changes

### artifact_call frame: verbs a script can issue to the Artifact tool

AppifactRepl scripts can issue Artifact tool actions like get, set, upload, and publish over a JSON protocol

**What**

A new internal protocol lets scripts running inside AppifactRepl (see the related entries on this tool) issue Artifact tool actions directly: reading or querying data (`get`/`list`/`query`), writing it (`set`/`update`/`delete`/`batch`), working with files (`read_file`/`read_files`/`list_files`), handling assets (`upload_asset`/`read_asset`), and publishing or opening the artifact. Messages are exchanged as one JSON object per line.

Each action is checked against the session's permissions individually, and can be refused, for example, if the Artifact tool's database actions or asset actions are turned off for that session.

**Why**

This lets a single script drive the full range of Artifact operations while still respecting the same per-action permission boundaries that apply outside the REPL.

- Area: Artifact REPL
- Tier: Under the hood
- Useful: 2/5
- Signal: 3/5
- Present in the build but not switched on

### Artifact 'read' output now appends REPL-tool routing hint, gated on REPL tool presence

Artifact read results now show a REPL routing hint only when the REPL tool is available, plus a per-type 'two steps' note

**What**

When the Artifact tool renders the result of a read, it appends extra text explaining how to proceed. This routing text is now produced by a new function, `fxn()`, which first checks whether the Artifact REPL tool is present and returns nothing if it isn't, instead of always producing the text as before.

A second new helper, `hur()`, looks up a per-Artifact-type "two steps" routing note keyed by the file's frontmatter name, and reports whether the referenced files were kept as files. This feeds into flags used elsewhere to track how a read was handled.

**Why**

This keeps the REPL-related guidance from appearing when the Artifact REPL tool (see related entries on AppifactRepl) isn't actually available in the session, and lets certain Artifact types show more specific two-step instructions after a read.

- Area: Artifact REPL
- Tier: Under the hood
- Useful: 2/5
- Signal: 3/5
- Present in the build but not switched on

### Tool-permission check gains a special case for the Artifact REPL tool

Tool-permission logic gains a dedicated check for disabling the Artifact REPL tool

**What**

The internal function that decides whether a tool should be filtered out as disabled now has a special case for the Artifact REPL tool. When that specific tool is being checked and no MCP (Model Context Protocol) server info is attached, a new helper, `H7t()`, evaluates the session's permission rules, ignoring any rules sourced from "tools narrowing." It treats the tool as disabled if there is a matching deny rule for it, or if a permission rule's content is made up only of whitespace or asterisks.

**Why**

This gives the Artifact REPL tool its own dedicated permission-disabling logic, separate from how other tools are enabled or disabled.

- Area: Permissions
- Tier: Under the hood
- Useful: 2/5
- Signal: 3/5
- Present in the build but not switched on

### New AppifactRepl tool wired into permission, read, and tool-list plumbing

New AppifactRepl tool wired into permissions, file-read tracking, and always-allowed tool handling

**What**

A new tool called `AppifactRepl`, described as a REPL for building Artifacts incrementally step by step across multiple calls, is now referenced throughout Claude Code's permission checking, file-read tracking, always-allowed tool list, and rule-matching logic.

It runs by spawning a child process, with dedicated error messages if that fails, such as "the pipe to the child failed" or "the spawn was refused." It's also integrated with Artifact publishing so that writes made through AppifactRepl don't trigger the automatic-open behavior that normal file writes do.

**Why**

This plumbs the new AppifactRepl tool into the same permission and tracking systems every other tool goes through, and avoids unexpectedly popping open an Artifact preview every time the REPL writes to it.

- Area: Artifact REPL
- Tier: Under the hood
- Useful: 2/5
- Signal: 3/5
- Present in the build but not switched on

### New background-runner epoch/retry constants for session failure handling

New retry timing and stale-session detection added to background session failure reporting

**What**

The background runner's failure-reporting path, covering `runner:session` and `runner:stuck` logging, gained new timing constants (500ms, 1000ms, 2000ms, and 3000ms) and an abort helper. These are used when retrying a failed attempt to post a failure result, and to detect when another runner has already taken over a session, logged as a "stale epoch" rejection.

**Why**

This makes background session failure handling more robust: retries are now timed explicitly, and a runner can tell when it's no longer the current owner of a session instead of continuing to report against it.

- Area: Elsewhere
- Tier: Under the hood
- Useful: 2/5
- Signal: 2/5

### Quickstart hint gains a "saved line" override for artifact publishing

Quickstart reminder text can now be overridden by a saved 'after quickstart' line

**What**

When creating a typed Artifact after a `quickstart` call, Claude Code shows a reminder that quickstart already listed the available design systems in the conversation. The function that builds that reminder now first checks an internal helper, `afterQuickstartSavedLine`, for a saved or customized version of the line, and only falls back to the generic wording if none is found.

**Why**

This allows the reminder text shown after a quickstart to be customized or overridden rather than always being the same generic message.

- Area: Elsewhere
- Tier: Under the hood
- Useful: 2/5
- Signal: 1/5

### Update-check output switched from one console-output helper to another

Update-check messages now printed through a different internal output helper

**What**

In the code that checks for and reports Claude Code updates, several messages, including the current version line, "Update available" notices, and "Claude Code is up to date" messages, now go through an internal output helper called `lr` instead of the previously used `ar`. The messages themselves are unchanged.

**Why**

This is an internal refactor with no expected change to what is shown when Claude Code checks for updates.

- Area: Elsewhere
- Tier: Under the hood
- Useful: 1/5
- Signal: 1/5

### Version/build metadata bump only (repeated across bundle chunks)

Internal version metadata bumped from 2.1.271 to 2.1.272 across the bundle

**What**

The embedded `VERSION`, `BUILD_TIME`, and `GIT_SHA` constants were updated from `2.1.271` to `2.1.272` in many places throughout the bundled code, where the same metadata block is duplicated across chunks.

**Why**

This is routine release bookkeeping with no behavior change on its own.

- Area: Elsewhere
- Tier: Under the hood
- Useful: 1/5
- Signal: 0/5

### Minor rename: xu() -> Ou() in stale background-process warning

Internal helper rename in the stale background-binary warning, no behavior change

**What**

A warning message shown when a background process is using a stale binary now has both of its code paths call the same internal helper function, `Ou()`, where one of them previously called a different helper, `xu()`.

**Why**

This is an internal cleanup with no visible effect on the warning shown to users.

- Area: Elsewhere
- Tier: Under the hood
- Useful: 1/5
- Signal: 0/5