The key that must never reach the browser.

Claude Code 2.1.292 spent 6 October closing holes in its own sandbox. The lesson for a published page is older than that release, and easier to get wrong when an agent is writing the HTML.

What shipped

Version 2.1.292 added an effort setting on the Agent tool, so a parent session can ask for a lighter sub-agent on a simple search and a heavier one on a hard edit. It also added a shorter path for installing a plugin from a marketplace. The security notes are the part worth reading slowly.

The release closed several ways a command could slip past the permission check. One of them involved network paths, the Windows-style UNC form, skipping the file-read prompt. Others involved staged upload copies, a tampered settings cache, and delete commands written with alternate path spellings so they no longer looked like rm of a home folder. A hotfix, 2.1.291, had landed the same day to repair regressions from the releases just before.

If you let an agent run while you are away from the desk, that changelog is the weekly reminder. The sandbox is a product that changes. Read the permission notes before you trust an unattended session with a folder that contains secrets.

Two different keys

A published page has a quieter version of the same mistake. Agents like to “make the form work” by pasting whatever credential they can see into the frontend. There are two kinds of keys, and they do not have the same job.

• An account token speaks as you. It can deploy, change who can open the project, and alter schema. It belongs in a terminal, an environment variable, or a password manager. It does not belong in HTML, in a public repository, or in a screenshot of a chat.
• A project key for the browser identifies one site and lets that site insert and read the rows you meant the public page to touch. It is fine for visitors to see, because seeing it does not hand them your account.

If the page only needs to store a waitlist email, the browser key is the one that goes in the JavaScript. The account token stays on your machine. Mixing them up means anyone who can view source can act as you.

A two-minute check

Before you send the link, search the folder you are about to publish. Include the built output, not only the source. Agents often inject the secret at build time.

1. Search for the account token, for Bearer, and for any variable named TOKEN, SECRET, or API_KEY inside index.html and the script files next to it.
2. Confirm the value in the page is the public project key, and that the requests it makes are the ones a visitor should be allowed to make. Saving a row is reasonable. Changing the table definition is not.
3. If a secret did land in the files, rotate it. Removing the line from the next deploy does not undo the copy already on someone else’s screen.

Effort settings do not replace this

The new effort dial is a cost and quality control. It does not decide which secrets are safe to publish. A cheap sub-agent can still copy a token into a script if the brief is vague and the token is sitting in the chat. Tell the agent which key is public. Then check the built files yourself. The sandbox vendors are closing their holes. The hole in a page you already shipped is yours to close.