Personas and bindings

Many State Cards can require the same Auth Persona. Bind the Persona on the current machine, then compatible Cards can use that local authentication capability without placing its raw value inside the ordinary portable State Card.

Common safe statuses are:

Status	Meaning	What to do
`READY`	The required local binding is available.	Reproduce the State Card.
`AUTH_BINDING_REQUIRED`	No compatible local binding exists.	Bind or re-authenticate the Persona.
`REAUTH_REQUIRED`	The saved session is no longer accepted.	Re-authenticate the Persona.
`AUTH_ORIGIN_MISMATCH`	The binding cannot be used for this origin.	Create a correctly scoped binding.
`AUTH_POLICY_DENIED`	Local credential policy refused the operation.	Check supported OS credential storage and project policy.
`AUTH_TARGET_MAPPING_REQUIRED`	The portable requirement has no exact Persona mapping for this target.	Choose a compatible local Persona or sign in.
`AUTH_ATTACHMENT_REQUIRED`	An offered Protected Persona needs a recipient decision.	Review it, then accept, decline, or import Card only.
`AUTH_ATTACHMENT_EXPIRED`	The protected transfer is no longer usable.	Import Card only or establish local authentication.
`AUTH_SESSION_REJECTED`	Material was installed but the configured signed-in checkpoint rejected it.	Sign in again.
`AUTH_SESSION_DEVICE_BOUND`	The session cannot be reused on this device.	Complete the normal sign-in flow; StatePort does not bypass MFA/passkeys.
`AUTH_VALIDATION_TIMEOUT`	The bounded post-login proof did not complete.	Retry or sign in again after checking the target.

An Auth Binding is machine-local and is not transferred by an ordinary State Card share. The recipient establishes their own compatible local authentication.

When you explicitly choose a dedicated local Persona for a different loopback current-code origin, StatePort can retarget only its localStorage or sessionStorage material for that run. Cookie/header material, remote origins and accepted protected attachments remain exact-scope and are not rewritten.

Create a Persona by signing in during an ordinary Capture. Capture Review proposes safe candidate names, types, origins and lifecycle, then Save State Card and Persona validates the final signed-in page and stores only the selected set behind the protected local boundary. A Card saved without the Persona still retains its non-secret sign-in requirement.

For a separate localhost app, create its Persona through a new managed Capture: open that exact local app, sign in during Capture, review the detected session items, and save the Card and Persona. Return to the original Card and choose the compatible Persona when offered. If no compatible Persona exists, the launcher reports that limitation. The current Desktop does not provide a Create local Persona shortcut from the Card or a Persona Manager in Settings. Use the available sign-in recovery for an existing Persona when offered, or capture a fresh sign-in. MFA/passkey/CAPTCHA steps remain human-completed; factors themselves are never copied.

CLI state auth-status and MCP inspect_auth return the same auth-interface-status/1.0.0 value-free status used by Desktop. They can tell an agent which human action is required, but cannot accept a Persona, create a mapping, read values or turn confirmed: true into authority.