[FEATURE] Cloud sessions: a sign-in form credential, filled without the model seeing the password

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

An Anthropic-hosted cloud session has no supported way to get past a web application's sign-in form.

API credentials solved this for API calls. The key stays outside the VM and the agent proxy attaches it per host: "The key never reaches Claude, the commands it runs, or the session's environment variables." (cloud environments)

A sign-in form is the case they do not reach:

• No credential type fits a form. The documented types are all API shapes: Bearer, Basic, Body parameter, AWS SigV4, GCP access token, GCP IAP, OAuth 2.0 JWT bearer, OAuth 2.0 client credentials, MCP Connector (list). Body parameter is described only as "A token the API expects in the request body or query string instead of a header."
• Environment variables are readable by the model. They become "ordinary environment variables that any command Claude runs can read." In a shared environment it is wider: "Anyone who uses the environment can read its environment variables and setup script." (same page)
• The password-manager fill needs a Mac and a person. It is "in beta for paid plans (Pro, Max, Team, Enterprise) using Claude Desktop on macOS", it "requires Claude in Chrome", and "You approve credential use per task" (help article). Driving Chrome from a cloud session does not change that: such tasks "still need the Claude Desktop app open and connected, even though your session runs in the cloud" (help article). A routine, or a session started from a phone with no Mac awake, cannot use it.
• Nobody can take over. Locally, "When Claude encounters a login page or CAPTCHA, it pauses and asks you to handle it manually." (Chrome docs) In a cloud session, "You don't get a shell into the session VM." (cloud environments)

So the only way through today is to put the password where the model can read it: the prompt, an environment variable, or a file. That is the exposure API credentials were built to remove.

Several open issues also report that sessions now decline to type a password even when the user supplies it (#78160, #78985, #94800). If that is the intended rule, a path owned by the harness is the only one left, and in a cloud session there is none.

Proposed Solution

Add one type to the existing credential list on a cloud environment: Sign-in form.

Setting it up, in the dialog that exists today:

1. Open the environment, then API credentials, then Add credential, and pick the type "Sign-in form".
2. Fill in a name, the allowed websites, a username and a password.
3. The password is write-only, as credentials already are: "You can't view the value again after saving."

In a session:

1. Claude sees the credential's name, its allowed websites and a per-session placeholder. It never sees the value.
2. Claude opens the sign-in page in the VM's browser and enters the placeholder in the password field.
3. The real value is swapped in outside the VM, and only when the form is sent to an allowed website. Any other destination receives the placeholder.
4. The session shows one line per use: the credential's name and the website, never the value.

Requirements:

• The value never enters model context, the transcript, the environment or a file in the VM.
• Setup scripts never receive it, as with API credentials today.
• It works unattended, including in routines. Approval is given once, by the person who saves the credential.
• Only a person with access to the environment dialog can add one. Repository files and page content cannot.

Two building blocks already exist at Anthropic. Either would satisfy this request:

• Placeholder substitution at the proxy. The local sandbox does it: "the sandboxed command sees a per-session sentinel value instead of the real one", and "Substitution covers headers and request bodies." (sandboxing) Managed Agents vaults do it too, including for "a form-encoded token request" (vaults).
• A fill into the page by the harness, as the password-manager integration does on desktop.

Alternative Solutions

| Tried | Why it falls short |
|---|---|
| Environment variable | Readable by the model and by everyone who uses the environment |
| Body parameter credential | Documented for API tokens; nothing documents a username and password sign-in |
| Test-only sign-in bypass in the app, used with a Bearer credential | Works today, but changes the product under test, and the real sign-in path is no longer what gets tested |
| Signing in locally and copying a session cookie into the VM | Puts a live session secret in the VM in plain text |
| Running with a desktop attached: Claude in Chrome, the desktop browser pane, or the password-manager fill | Needs the computer on and a person present, so unattended runs are lost |
| A remote MCP server of my own that runs the browser and holds the password | Possible on paper, but it means hosting and securing a browser service myself, which a cloud session is meant to remove |
| A self-hosted environment | Team and Enterprise only, and the organization has to operate the runners |
| MCP URL-mode elicitation | Signs the user in to an MCP server in their own browser; it does not sign the VM's browser in to the app, and the session "can expire during that wait" (docs) |

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. A team has a staging site with a seeded test account.
2. After each change, a cloud session or routine should open the site, sign in as the test user, walk the changed screens at phone and desktop width, and attach screenshots to the pull request.
3. Today the session reaches the sign-in page and stops. The other choice is to put the password in an environment variable, where the model and every user of the environment can read it.
4. With this feature the owner saves the test account once, bound to the staging website. Sessions sign in unattended, and the password appears nowhere in the transcript or the pull request.

Additional Context

Related issues, and how this differs

• #32733 asks for secrets in cloud sessions, delivered as environment variables. API credentials answered much of it. This is the part a header or body token cannot reach.
• #96949 is the closest. It asks for the same guarantee, including unattended use, for the desktop app, simulators and devices. This is the same idea for a session with no desktop attached. A cloud VM has no password manager and no keychain, so the credential has to live on the cloud environment.
• #83380, #96762 and #88165 ask for a password-manager handoff that a person approves per use. This asks for the unattended case, with no password manager and no desktop.
• #82668 asked for a credential broker for browser automation in the local CLI. It was closed as inactive.
• #90301 asks for a masked prompt in the local CLI and rules out cloud sessions.

What this depends on

A browser has to work inside the VM. The documented tool list includes chromedriver and no browser (installed tools); a setup script can install one.

In a cloud session run on 2026-09-28, Chromium driven by Playwright loaded public HTTPS pages and took screenshots, once the proxy's certificate authority had been imported into the browser's certificate store. So a browser can work there, and its traffic passes through the proxy.

Others report that Chromium cannot connect through the cloud proxy: #11791, #73564, #90521, #93056. A request for browser tools in cloud sessions, #75632, was closed as inactive.

Plan

MAX. API credentials are available on this plan, and the gap above remains.

Prior art for the same guarantee in a hosted browser

• "Credentials entered through the secure sign-in form go directly to the browser and are not visible to the model." (ChatGPT browser docs)
• "The LLM only sees placeholders" (Browser Use)
• "Stagehand exposes only the variable names to the model and substitutes the real values locally" (Stagehand)

Known limits, stated up front

• Substitution at the proxy does not help a site that hashes or encrypts the password in the page before sending it. A fill into the page does.
• A site that echoes the password back, in its response or in the page, would expose it. The desktop integration already guards against this: "1Password checks that no credentials were exposed on the page."
• CAPTCHA, single sign-on and passkeys are out of scope.
• It is meant for test and service accounts, not personal ones.
• API credentials are Pro and Max only today: "They aren't available on Team or Enterprise plans yet". This type would follow the same availability.