diff --git a/.changeset/expo-native-use-settings.md b/.changeset/expo-native-use-settings.md
new file mode 100644
index 00000000000..a845151cc84
--- /dev/null
+++ b/.changeset/expo-native-use-settings.md
@@ -0,0 +1,2 @@
+---
+---
diff --git a/.claude/skills/verify-clerk-expo/SKILL.md b/.claude/skills/verify-clerk-expo/SKILL.md
index 1bb6e4c1514..cb7dcb56b67 100644
--- a/.claude/skills/verify-clerk-expo/SKILL.md
+++ b/.claude/skills/verify-clerk-expo/SKILL.md
@@ -11,7 +11,7 @@ The tests are an ordinary e2e project. `e2e.config.ts` and `specs/` run under `n
 
 No change to `@clerk/expo` or `@clerk/expo-native-components` UI or auth behavior is done until a simulator or emulator shows the changed behavior, on each platform the change touches. A `run` on the test app is one way to show it. An app of your own that exercises the change is just as good.
 
-Run every command from the repo root. In the prose below, `doctor`, `up`, `run`, `screen`, `attach`, and `down` are verbs of that CLI. The tests and the CLI are the Node package `integration/expo-native/`, and paths that begin `specs/`, `src/`, `test/`, or `.verify/` are inside it. `features/` and `references/` are beside this file. Every verb but `attach` takes `--platform ios|android`, and iOS is the default. Every error prints a `fix` line. Every verb takes `--json`, and [CLI output](references/output.md) has its shape, the exit codes, and the error codes.
+Run every command from the repo root. In the prose below, `doctor`, `up`, `run`, `screen`, `attach`, `down`, and `settings` are verbs of that CLI. The tests and the CLI are the Node package `integration/expo-native/`, and paths that begin `specs/`, `src/`, `test/`, or `.verify/` are inside it. `features/` and `references/` are beside this file. Every verb but `attach` and `settings` takes `--platform ios|android`, and iOS is the default. Every error prints a `fix` line. Every verb takes `--json`, and [CLI output](references/output.md) has its shape, the exit codes, and the error codes.
 
 The test app links `@clerk/expo`, `@clerk/expo-native-components`, `@clerk/expo-biometrics`, and `@clerk/expo-google-signin` from the workspace. It does not install `@clerk/expo-passkeys`, so the skill cannot verify passkeys.
 
@@ -61,7 +61,7 @@ The package is outside the pnpm workspace, so `npm ci` installs its pinned `e2e`
 
 On a local device a JS change in `packages/expo/src` or in the test app reaches the app with no build. A JS change in `packages/expo-native-components/src`, where AuthView, UserButton, and UserProfileView are, makes the next `up` or `run` rebuild that package first. Before the specs start, `run` waits until the watch build has caught up and Metro serves the current code, and it fails with `NOT_READY` and the path of the Metro log when Metro never does. [How a change reaches the app](references/freshness.md) has the native inputs, the checks, the ports, and the logs. It also says what to do after a change to another workspace package, such as `@clerk/clerk-js` or `@clerk/shared`. While Metro runs, never run `pnpm --filter @clerk/expo build` or a build of a package that `@clerk/expo` depends on, because the build deletes the `dist` that Metro serves.
 
-A worktree can hold one lane of each platform. The two lanes share the watch build and the application, and each has its own Metro. Run them one after the other. The application serves one run at a time, because a run can change its settings. A `run` that starts while a run on the other platform is driving leases its device and then fails with `DEVICE_BUSY`, and its fix is to let that run finish and rerun.
+A worktree can hold one lane of each platform. The two lanes share the watch build and the application, and each has its own Metro. Run them one after the other. The application serves one run at a time, because a test in a run can change its settings. A `run` that starts while a run on the other platform is driving leases its device and then fails with `DEVICE_BUSY`, and its fix is to let that run finish and rerun.
 
 A Mac has four iOS lanes and two Android lanes, shared by every worktree on it. When all are taken, `up` and `run` fail with `POOL_FULL`, and `--wait <seconds>` on either verb waits for a lane. The CLI drives only the simulators and emulators that it creates. [Local devices](references/devices.md) says how to find a lane's UDID or serial.
 
@@ -112,7 +112,7 @@ $ integration/expo-native/bin/control-clerk-expo run native-auth-view native-js-
 $ integration/expo-native/bin/control-clerk-expo screen --platform ios                        # the UI tree that is on screen now; --png adds a screenshot
 ```
 
-`run --all` runs every committed spec. `run` also takes `--grep <regex>`, `--retries <n>`, `--max-failures <n>`, `--no-video`, and `--wait <seconds>`. `--retries <n>` runs a test again, up to `n` more times, when an assertion failed, the test threw an error, or the test ran out of time. A test that e2e reports as a machine failure, such as an `ENGINE_FAILURE` when an `open` or a screenshot times out in agent-device, gets one attempt whatever `n` is. A driver error e2e reports as a test error, such as a stale node or an action that timed out, is retried like any other. The default is 0, so a run of your own change shows exactly what happened. `--max-failures <n>` stops a settings group once `n` of its tests have failed. A test that the limit stopped before it started prints `FAIL` with `not run: failure-limit`, and `run` exits 1. Without the flag, a run has no limit. The wait covers a free lane and another `run` in this worktree that holds the device. A spec limited to one platform with `test(title, { platforms: ['ios'] }, fn)` reports as skipped on the other.
+`run --all` runs every committed spec. `run` also takes `--grep <regex>`, `--retries <n>`, `--max-failures <n>`, `--no-video`, and `--wait <seconds>`. `--retries <n>` runs a test again, up to `n` more times, when an assertion failed, the test threw an error, or the test ran out of time. A test that e2e reports as a machine failure, such as an `ENGINE_FAILURE` when an `open` or a screenshot times out in agent-device, gets one attempt whatever `n` is. A driver error e2e reports as a test error, such as a stale node or an action that timed out, is retried like any other. The default is 0, so a run of your own change shows exactly what happened. `--max-failures <n>` stops the run once `n` of its tests have failed. A test that the limit stopped before it started prints `FAIL` with `not run: failure-limit`, and `run` exits 1. Without the flag, a run has no limit. The wait covers a free lane and another `run` in this worktree that holds the device. A spec limited to one platform with `test(title, { platforms: ['ios'] }, fn)` reports as skipped on the other.
 
 For a JS change on a local device, edit the source and `run` the spec, with no `up` in between. For a change to a native input, the same `run` rebuilds the dev client first. On a remote device, commit and push, then `run`.
 
@@ -156,7 +156,7 @@ The test app has a screen or a small flow of its own only where the native views
 
 On iOS, locate nodes of the native views with the SDK's identifiers, such as `screen.getByTestId('clerk.auth.start.identifier')`. The clerk-android release that `@clerk/expo-native-components` pins sets the same `clerk.*` names as resource ids, but `specs/native.ts` still finds the Android native views by text. The home has `e2e.*` testIDs, which `host.app` holds, and the test app's other screens have `verify.*` testIDs, on both platforms. All of these identifiers are internal test hooks, not public API, and they can change. Every spec keeps at least one exact assertion on an identifier or on visible text. To assert on the text of a node, use `await expect(locator).toHaveText('...')`.
 
-A spec file that needs other settings than the standard ones has a settings file beside it, with the same name and `.settings.json` in place of `.e2e.ts`. `run` puts the application on those settings before the tests in that spec file start. Any other JSON file under `specs/` stops every run. [Test instances](references/instances.md) has the rules for a declaration.
+Every test starts on the standard settings. A test that needs other settings calls `host.useSettings({ config, environment? })`, and the CLI puts every leaf it changed back when the test ends. [Test instances](references/instances.md) has the call, the restore, and the leaves that tests often change. To see which settings are on or off, run `integration/expo-native/bin/control-clerk-expo settings <prefix>`, such as `settings auth_multi_factor`.
 
 ### Check your work
 
@@ -184,7 +184,7 @@ Every `run` writes `.verify/runs/<run-id>/` and prints its path.
 
 | File                      | What it holds                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `run.json`                | The record: `results` per spec, `platform`, `backend`, `gitHead`, `dirty`, `build`, `device`, `identities`, `settings`, and `tainted`                                                                                                                                                                                                                                                                                                                          |
+| `run.json`                | The record: `results` per spec, `platform`, `backend`, `gitHead`, `dirty`, `build`, `device`, `identities`, `settings` (one entry per `host.useSettings` call), and `tainted`                                                                                                                                                                                                                                                                                  |
 | `video.mp4`               | The run, from the first `host.launch` to the end, recorded by `simctl io recordVideo` on iOS or `adb shell screenrecord` on Android. Just before that launch, `run` closes the app and starts the recorder, so the video opens on the device's home screen for a moment and then on the app being launched. A run in which no test calls `host.launch` has no video, and `run` prints a `video` line that says so                                              |
 | `evidence-marks.jsonl`    | When each `host.evidence` block started and ended, and when and where each `host.tap` and `host.fill` tapped, in a run that records evidence. `run.json` keeps them as `evidenceSpans` and `evidenceTaps`, in seconds of the video                                                                                                                                                                                                                             |
 | `video-cut.mp4`           | What `attach --video` last posted for this run: the marked part of `video.mp4`. `video.mp4` stays as recorded                                                                                                                                                                                                                                                                                                                                                  |
@@ -192,7 +192,7 @@ Every `run` writes `.verify/runs/<run-id>/` and prints its path.
 | `app.log`                 | Device log lines. On Android they include the app's `[verify]` console lines. On a local iOS device they are native lines only, and the `[verify]` lines are in `.verify/runtime/metro-<port>.log`. The test app writes one `[verify]` line each time its screen, user, session, or launch error changes, with the `launchId` that a failed `host.launch` names. No spec reads these lines. They are for diagnosing a failure that the screen does not explain |
 | `e2e/`, `e2e.log`         | e2e's `report.json` and `junit.xml`, its failure pages, and its console output                                                                                                                                                                                                                                                                                                                                                                                 |
 | `driver/`                 | `summary.txt`, which says what agent-device state the run found and what it copied, and the part of agent-device's `daemon.log`, and on iOS of the XCTest runner's `runner.log`, that the run added. The copies leave out typed text. They are for a failure that the driver caused, such as a daemon that did not start or a screen read that hung                                                                                                            |
-| `specs/`                  | A copy of every spec the run used, with its settings file when it has one                                                                                                                                                                                                                                                                                                                                                                                      |
+| `specs/`                  | A copy of every spec the run used                                                                                                                                                                                                                                                                                                                                                                                                                              |
 
 A proof drives the real user path. The video and the screenshots show the action and its result as a user sees them. It checks side effects where the app shows them, such as the user ID and the session ID on the home, not only that the last screen appeared.
 
@@ -233,7 +233,7 @@ To make the before run, `run` the spec of your change on the build without the c
 
 For screenshots, show each screen the change touches, and each state of a screen that it touches, in a before and after of its own. That includes a state the change should leave as it was, because its pair shows that it did. Write one spec file with one test per state, each ending in its own `host.screenshot(label)`. On each platform you show, run it once without the change and once with it, and pass every label to one `attach`, one `--screenshot <label>` each. The table of that platform then has a row for each state.
 
-Some states are out of reach for a test user on the standard settings with the default roles. Try a settings file for the spec, or test data that the spec seeds, first. When neither reaches it, force the state with a small local patch to the build. Never commit or push the patch. Put the same patch on the before build and the after build, and run both on a local device, because `attach` refuses a run on a session build with uncommitted changes. In the pull request, say exactly what the patch changed and why no test user could reach the state without it.
+Some states are out of reach for a test user on the standard settings with the default roles. Try `host.useSettings` in the spec, or test data that the spec seeds, first. When neither reaches it, force the state with a small local patch to the build. Never commit or push the patch. Put the same patch on the before build and the after build, and run both on a local device, because `attach` refuses a run on a session build with uncommitted changes. In the pull request, say exactly what the patch changed and why no test user could reach the state without it.
 
 `attach` puts the files in the description of the pull request with `gh pr edit --attach`. It writes one block for the platform of the run, between the comments `<!-- verify-evidence:ios -->` and `<!-- /verify-evidence:ios -->`, or the same two with `android`. The block is a line and then one or more tables. The line leads with the result and names the run, the device, the commit, and how many tests passed. With `--before` it also names the before run, its commit, and how many of its tests passed. With `--before`, one table has a `Before` and an `After` column, and a row for each screenshot or one row for the video. Without it, the screenshots are two across, each under its label in code font, and the video is alone in a table under its name. Each screenshot is 280 pixels wide.
 
@@ -255,7 +255,7 @@ Work in this order, with one `up` for both runs: make the branch and `git push`
 
 On a local device `attach` writes the description itself, and no run needs a push. A remote session builds only the commit it was started on and later commits of the branch, so its before run comes before the push of the change. Its evidence reaches the description about a minute after `down`.
 
-When the change is already committed or pushed, make the before run on its base commit in this worktree, so the run lands in this checkout's `.verify/runs/`. A spec in `specs/explored/` stays through the switch, because that directory is gitignored. A committed spec of the change is not on the base, so copy it, and its settings file if it has one, to `specs/explored/` first and change its import to `'../fixtures.ts'`.
+When the change is already committed or pushed, make the before run on its base commit in this worktree, so the run lands in this checkout's `.verify/runs/`. A spec in `specs/explored/` stays through the switch, because that directory is gitignored. A committed spec of the change is not on the base, so copy it to `specs/explored/` first and change its import to `'../fixtures.ts'`.
 
 ```console
 $ git switch -c <branch>-before "$(git merge-base origin/main HEAD)"
diff --git a/.claude/skills/verify-clerk-expo/features/native-auth-view.md b/.claude/skills/verify-clerk-expo/features/native-auth-view.md
index 29fb9a4fc8c..1c18d3fa8c0 100644
--- a/.claude/skills/verify-clerk-expo/features/native-auth-view.md
+++ b/.claude/skills/verify-clerk-expo/features/native-auth-view.md
@@ -39,7 +39,7 @@ Preconditions:
 - `@clerk/expo-native-components` ships the clerk-ios release pinned in `packages/expo-native-components/ios/ClerkExpo.podspec`, so iOS has the `clerk.auth.*` identifiers. It ships the clerk-android release pinned in `packages/expo-native-components/android/build.gradle`. That release sets the same `clerk.*` names as resource ids on AuthView. Android specs still find AuthView by its text (`Enter your email or username`, `Continue`), in `specs/native.ts`. Switch those locators to `getByTestId` once a run shows the resource ids in the screen tree.
 - The test app puts nothing above, below, or over AuthView. On iOS the screen tree leaves out what a modal covers, so the home's nodes are not in the tree while the modal AuthView is up.
 - On Android, an AuthView that can be dismissed shows a close button with the label `Close`, and `Sign in full screen` shows none. No spec taps that button. The back button closes the AuthView that the home opened.
-- The standard settings have the email link off, because a test address gets no mail, so a run has no link to follow. With the link on, AuthView opens the email link screen first (`Open email app`), which has no code field, and a spec that expects `clerk.auth.signIn.code` right after Continue times out. A spec that needs the link declares `auth_email.sign_in_strategies` in a settings file.
+- The standard settings have the email link off, because a test address gets no mail, so a run has no link to follow. With the link on, AuthView opens the email link screen first (`Open email app`), which has no code field, and a spec that expects `clerk.auth.signIn.code` right after Continue times out. A test that needs the link turns it on with `host.useSettings`, which sets `auth_email.sign_in_strategies` and `auth_email.verification_strategies`.
 - On Android the spec does not use the code field's tag. `nativeAuth` in `specs/native.ts` waits for `Check your email` and types the code into the last text field on that screen. The pinned clerk-android release names that field `clerk.auth.signIn.code`.
 - Close the modal AuthView with `closeNativeAuth` from `specs/native.ts`. On iOS one tap on the close button can do nothing, and `closeNativeAuth` taps the button once more when it is still on screen three seconds after the first tap.
 - The logo is a React Native view that AuthView hosts. The spec finds it by its text on both platforms.
diff --git a/.claude/skills/verify-clerk-expo/features/native-modules.md b/.claude/skills/verify-clerk-expo/features/native-modules.md
index 3b887ed0587..eceb78db247 100644
--- a/.claude/skills/verify-clerk-expo/features/native-modules.md
+++ b/.claude/skills/verify-clerk-expo/features/native-modules.md
@@ -18,7 +18,7 @@ An app that uses `useSignInWithGoogle` from `@clerk/expo/google` or `useBiometri
 Preconditions:
 
 - `up` has built the test app. The build links `@clerk/expo-google-signin` and `@clerk/expo-biometrics` from the workspace. The test app's `app.json` lists the `@clerk/expo-google-signin` config plugin, beside those of `@clerk/expo` and `@clerk/expo-native-components`, and holds three placeholder values under `extra`: a web client ID, an iOS client ID, and the iOS URL scheme that the plugin registers. They belong to no Google project.
-- `specs/features/native-modules/biometric-availability.settings.json` turns biometric sign-in on for the instance (`auth_biometric.used_for_sign_in`). The hook reads that as `trusted_device_sign_in_enabled` in the environment's native settings, which the file declares as the expected value. `run` applies it before the test of that spec file. The Google spec file runs on the standard settings, so a run of both has two settings groups.
+- The biometric test starts with `host.useSettings`, which turns biometric sign-in on for the instance (`auth_biometric.used_for_sign_in`). The hook reads that as `trusted_device_sign_in_enabled` in the environment's native settings, and the call names `auth_config.native_settings.trusted_device_sign_in_enabled` as the leaf that shows the change. The CLI puts the setting back when the test ends. The Google test runs on the standard settings.
 
 - **Google sign-in.** Run `integration/expo-native/bin/control-clerk-expo run native-modules/google-sign-in --platform ios`, and again with `--platform android`. The test taps `Native modules` on the home and taps `google-sign-in-button`. On iOS it waits for the system prompt that names `accounts.google.com` and dismisses it with `device.alert('dismiss')`. It then expects `google-result` to say `Google sign-in was cancelled`. On Android it waits for a node whose id begins `com.google.android.gms:id/`, which is a page of Google Play services, and presses back once. When `google-result` appears within 5 seconds, it expects `Google sign-in was cancelled`, as on iOS. When nothing appears, it force-stops Google Play services with `adb shell am force-stop com.google.android.gms` and does not check the result. Either way it then expects no `com.google.android.gms:id/` node on screen. That last check matters: Google Play services keeps its add-account flow running after the app is force-stopped, and its next page would otherwise cover whichever test runs next. For the same reason, when any step after the tap on `google-sign-in-button` fails on Android, the test force-stops Google Play services before it reports the failure. Screenshots `google-system-prompt` always, and `google-cancelled` when the app reported the cancel.
 - **Biometric availability.** Run `run native-modules/biometric-availability` on each platform. The test opens the same screen, taps `biometric-availability-button`, and expects `biometric-availability-result` to say `biometric availability: biometric_authentication_unavailable` on iOS and `biometric availability: no_local_credential` on Android. Screenshot `biometric-availability`.
diff --git a/.claude/skills/verify-clerk-expo/references/instances.md b/.claude/skills/verify-clerk-expo/references/instances.md
index 955904da0b9..4dad1d9588f 100644
--- a/.claude/skills/verify-clerk-expo/references/instances.md
+++ b/.claude/skills/verify-clerk-expo/references/instances.md
@@ -1,6 +1,6 @@
 # Test instances
 
-Each worktree has one Clerk application of its own. `up` creates it through Clerk's Platform API, specs run on its development instance, and `down` deletes it. The two platforms of a worktree share it. It serves one run at a time, because a run can change its settings, so a `run` that starts while a run on the other platform is driving fails with `DEVICE_BUSY` (see Launch in `SKILL.md`). Nothing is shared with another worktree or another repository, so a spec never meets users or settings that it did not make.
+Each worktree has one Clerk application of its own. `up` creates it through Clerk's Platform API, specs run on its development instance, and `down` deletes it. The two platforms of a worktree share it. It serves one run at a time, because a test in a run can change its settings, so a `run` that starts while a run on the other platform is driving fails with `DEVICE_BUSY` (see Launch in `SKILL.md`). Nothing is shared with another worktree or another repository, so a spec never meets users or settings that it did not make.
 
 ## The standard settings
 
@@ -11,46 +11,77 @@ Each worktree has one Clerk application of its own. `up` creates it through Cler
 
 After the CLI configures a new application, it reads that public environment. A difference in one of those leaves fails with `INSTANCE_MISCONFIGURED` and names the setting. Run `down`, then `up` once more. If it fails again, Clerk changed what a setting does. Say so in your report, and do not edit the file as part of unrelated work, because three repositories share it.
 
-The CLI checks those 62 leaves and the leaves a settings file declares, and no others. The public environment has about 150 more leaves. One of them can differ between two applications, or move when a declaration is applied, and no check reports it. A spec that depends on such a leaf lists it in its settings file.
+## Change settings in a test
 
-## Declare other settings
+Every test starts on the standard settings. A test that needs another setting calls `host.useSettings` with the Platform API config leaves to change, each by its full dotted name:
 
-A spec file that runs on the standard settings declares nothing. One committed spec of this repository declares settings, `specs/features/native-modules/biometric-availability.e2e.ts`, which turns biometric sign-in on. A spec file that needs other settings has a settings file beside it, with the same name and `.settings.json` in place of `.e2e.ts`. For `specs/features/<feature>/<name>.e2e.ts`, that file is `specs/features/<feature>/<name>.settings.json`:
+```ts
+await host.useSettings({ config: { 'auth_multi_factor.required_for_sign_up': true } });
+```
+
+The CLI reads the value that each leaf has now, changes it, and waits until the instance's public `/v1/environment` shows the change. Turning a feature off is the same call with the other value:
+
+```ts
+await host.useSettings({ config: { 'auth_multi_factor.authenticator_app.enabled': false } });
+```
+
+`environment` is optional. Without it, the CLI waits until any leaf of the public environment changes, up to 15 seconds, and records the leaves that changed. A setting that moves no public leaf goes on after the 15 seconds, and the CLI prints a `settings` line that says so. When you know the leaf that shows the change, name it. The wait then checks exactly that leaf, and a wrong expectation fails the call:
 
-```json
-{
-  "config": { "organization_settings": { "force_organization_selection": true } },
-  "environment": { "organization_settings.force_organization_selection": true }
-}
+```ts
+await host.useSettings({
+  config: { 'organization_settings.force_organization_selection': true },
+  environment: { 'organization_settings.force_organization_selection': true },
+});
 ```
 
-`config` is a fragment of Clerk's Platform API instance config. `environment` lists the leaves of the public `/v1/environment` that the change moves, each by its full dotted path and with its new value. The declaration applies to every test in the spec file, so tests that need different settings go in different spec files.
+Call `host.useSettings` anywhere in a test, as many times as it needs. A call changes the settings from that point on. Clerk's servers apply the change at once, so a session task that the change requires appears without a relaunch. The native SDK screens can still show the settings that the app read at launch: on Android, the setup-MFA task kept offering an authenticator app that a test turned off after launch, until the app launched again, and on iOS it showed the change at once. Call `host.launch()` after `host.useSettings`, as `biometric-availability` does, unless the test is about an app that is already running.
 
-The CLI reads the settings file and never runs a spec to learn its settings. It refuses a declaration that breaks one of these rules, with a fix line that says what to write.
+Any leaf of the instance config works, not only the leaves in `base.json`. Clerk checks the request with a dry run before anything changes. A leaf that does not exist fails the call and lists the leaves beside it. A value Clerk refuses, or would store differently, also fails the call, and nothing changes.
 
-- The settings file is one JSON object that holds `config` and `environment` and nothing else. JSON takes no comment and no trailing comma.
-- Every JSON file under `specs/` is the settings file of a spec beside it. `run` and `doctor` refuse any other JSON file there, so a misnamed settings file is never left out in silence.
-- Settings are declared only in the settings file.
-- Every `config` leaf has a standard value under `config` in `base.json`, and at least one declared value differs from its standard value.
-- An `environment` leaf that `base.json` lists differs from its standard value.
-- Every leaf of `environment` in `base.json` that the change moves is listed. When one is missing, the failure lists the missing leaves with their values, ready to paste into `environment`.
-- Two settings files that declare the same `config` expect the same value of every leaf that both list.
+To find the name of an `environment` leaf, read `environment` in `base.json`. A leaf that is not there has the dotted path of its value in the JSON that the instance's public `/v1/environment` returns. The Platform API cannot set reverification, the development-mode banner, test mode, or PII protection off.
 
-The CLI cannot check an `environment` leaf that `base.json` does not list until it applies the change. The group then fails if the instance does not show the declared value within 15 seconds. The error says what the instance shows for that leaf, or that its public environment has no such leaf, which is how a misspelt leaf fails.
+## Restore
 
-To find the name of a leaf, read `environment` in `base.json`. A leaf that is not there has the dotted path of its value in the JSON that the instance's public `/v1/environment` returns. The Platform API cannot set reverification, the development-mode banner, test mode, or PII protection off.
+When a test ends, pass or fail, the CLI puts back every leaf that the test changed, to the value it read before the first change. A leaf changed twice goes back to its value before the first change. The next test starts on the standard settings again.
 
-## How `run` applies declarations
+The restore runs in three places, so a crash does not leave the application changed:
 
-`run` reads the settings files of the spec files it selected, groups the spec files by declaration, and runs each group in its own e2e invocation. A run of specs that all use the standard settings is one group, and it prints one line:
+- The test fixture restores when the test ends.
+- `run` restores after e2e exits, in case e2e was stopped before the fixture could.
+- The next `run` or `up` restores what a crashed CLI left. The CLI writes the old values to the worktree's state file before it changes anything, so it can always put them back.
+
+`run.json` has one `settings` entry per call: `at` is the spec line that called `host.useSettings`, `changed` lists each leaf with `from` and `to`, `shown` lists the environment leaves that showed the change, and `restored` says the leaves went back. `attach` refuses a run with an entry that was not restored.
+
+## See the settings
+
+`settings` prints the live config of this worktree's application, one leaf per line, with its exact dotted name and value. Each line pastes into `config`. Name a prefix to see part of it:
 
 ```console
-settings standard  already on <application>
+$ integration/expo-native/bin/control-clerk-expo settings auth_multi_factor
+settings  app_… (verify-throwaway-…)  no change a test made is pending
+"auth_multi_factor.authenticator_app.enabled": true,
+"auth_multi_factor.backup_code.enabled": true,
+"auth_multi_factor.required_for_sign_in": false,
+"auth_multi_factor.required_for_sign_up": false,
 ```
 
-Each group writes its own e2e directory in the run directory, in the order the groups ran: `e2e/`, `e2e-2/`, `e2e-3/`.
+`settings` reads Clerk's Platform API and never the device, so it works the same with a local and a remote device. It needs the application that `up` creates. When a crash left changes in place, its first line says how many leaves the next `run` or `up` restores.
+
+## Settings tests often change
+
+| Setting                      | Config leaf                                                            | Example                                                                                                                                 |
+| ---------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| MFA required at sign-up      | `auth_multi_factor.required_for_sign_up`                               | `{ 'auth_multi_factor.required_for_sign_up': true }`                                                                                    |
+| MFA required at sign-in      | `auth_multi_factor.required_for_sign_in`                               | `{ 'auth_multi_factor.required_for_sign_in': true }`                                                                                    |
+| Authenticator app            | `auth_multi_factor.authenticator_app.enabled`                          | `{ 'auth_multi_factor.authenticator_app.enabled': false }`                                                                              |
+| Backup codes                 | `auth_multi_factor.backup_code.enabled`                                | `{ 'auth_multi_factor.backup_code.enabled': false }`                                                                                    |
+| Email link                   | `auth_email.sign_in_strategies`, `auth_email.verification_strategies`  | `{ 'auth_email.sign_in_strategies': ['email_code', 'email_link'], 'auth_email.verification_strategies': ['email_code', 'email_link'] }` |
+| Password                     | `auth_password.enabled`, `auth_password.required`                      | `{ 'auth_password.required': false }`                                                                                                   |
+| Username                     | `auth_username.used_for_sign_in`, `auth_username.required_for_sign_up` | `{ 'auth_username.required_for_sign_up': true }`                                                                                        |
+| Organizations                | `organization_settings.enabled`                                        | `{ 'organization_settings.enabled': false }`                                                                                            |
+| Force organization selection | `organization_settings.force_organization_selection`                   | `{ 'organization_settings.force_organization_selection': true }`                                                                        |
 
-A declaration that breaks a rule the CLI can check from the file stops `run` before it builds or leases anything. A declaration that Clerk refuses, or whose `environment` does not match what the instance shows after the change, fails its own group, and the run goes on to the next group.
+An array leaf is set whole: name every value it keeps. The standard values are in `config` of `base.json`, and `settings` prints the live ones.
 
 ## The credential
 
@@ -58,7 +89,7 @@ One team key creates, changes, and deletes the application, and reads its secret
 
 Before it asks 1Password, the CLI sends one request with no key. In a cloud environment that holds the key as an API credential for `api.clerk.com`, the environment adds the key after the request leaves the machine, so that request succeeds and no key is ever in the session. The output then names the source as `a key attached outside this machine (no key is in this process)`. [Remote devices](remote.md) has the setup.
 
-`doctor` checks the credential every time and names its source in the `instances` line. `up`, `run`, and a `down` that deletes an application use it. `screen` and `attach` never use it.
+`doctor` checks the credential every time and names its source in the `instances` line. `up`, `run`, `settings`, and a `down` that deletes an application use it. `screen` and `attach` never use it.
 
 With no credential, `doctor` fails `instances` and prints how to supply one. `up` and `run` fail with `KEYS_MISSING` before they lease a device. `down` releases the device first and then fails the same way. `down` with the credential deletes the application later.
 
diff --git a/.claude/skills/verify-clerk-expo/references/output.md b/.claude/skills/verify-clerk-expo/references/output.md
index 8bcf4706911..d1895abc7f1 100644
--- a/.claude/skills/verify-clerk-expo/references/output.md
+++ b/.claude/skills/verify-clerk-expo/references/output.md
@@ -8,7 +8,7 @@ A verb prints progress lines to stderr while it works and its result to stdout w
 
 Every verb takes `--json`. The verb then prints no progress lines, and prints one JSON object to stdout.
 
-On success the object is `{ "ok": true, "verb": "<verb>", ... }`. The remaining keys depend on the verb. `src/core/types.ts` of `@clerk/internal-mobile-e2e` defines them as `DoctorReport`, `UpResult`, `RunResult`, `ScreenResult`, `AttachResult`, and `DownResult`.
+On success the object is `{ "ok": true, "verb": "<verb>", ... }`. The remaining keys depend on the verb. `src/core/types.ts` of `@clerk/internal-mobile-e2e` defines them as `DoctorReport`, `UpResult`, `RunResult`, `ScreenResult`, `AttachResult`, `DownResult`, and `SettingsResult`.
 
 On an error the object is `{ "ok": false, "error": { "code", "message", "fix", "retryable" } }`.
 
@@ -33,7 +33,7 @@ On an error the object is `{ "ok": false, "error": { "code", "message", "fix", "
 
 | Code                     | Meaning                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
 | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `USAGE`                  | The command line, a spec's declaration, or an environment variable is malformed                                                                                                                                                                                                                                                                                                                                                                                                    |
+| `USAGE`                  | The command line or an environment variable is malformed                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | `NOT_READY`              | A precondition is missing, such as Metro that does not serve the current code. The fix names it                                                                                                                                                                                                                                                                                                                                                                                    |
 | `POOL_FULL`              | All four iOS lanes, or both Android lanes, on this machine are in use                                                                                                                                                                                                                                                                                                                                                                                                              |
 | `DEVICE_BUSY`            | Another command in this worktree is driving the device, or a run on the other platform is using this worktree's application                                                                                                                                                                                                                                                                                                                                                        |
diff --git a/integration/expo-native/README.md b/integration/expo-native/README.md
index 8e2eb8776c5..34cf1bdbbeb 100644
--- a/integration/expo-native/README.md
+++ b/integration/expo-native/README.md
@@ -40,7 +40,7 @@ To run against a dev client instead, `integration/expo-native/bin/control-clerk-
 
 ## The instance
 
-The tests expect the settings in `src/core/instances/base.json` of `@clerk/internal-mobile-e2e`, which the CLI puts on the application it creates. On an instance with those settings, every test file that has no settings file beside it passes by hand.
+The tests expect the settings in `src/core/instances/base.json` of `@clerk/internal-mobile-e2e`, which the CLI puts on the application it creates. On an instance with those settings, every test that does not call `host.useSettings` passes by hand.
 
 An instance left at Clerk's defaults passes only part of the suite. The tests that sign in with a ticket, or sign up with an email address and a password, pass. The tests that need a phone number, an email code at sign-in, organizations, or a second account on the device fail, because a new instance has none of those turned on.
 
@@ -48,11 +48,11 @@ Every run creates users with addresses like `maya.7c1e+clerk_test@example.com` a
 
 ## Test files that need the CLI
 
-This test file has a `.settings.json` file beside it, and passes only on an instance with those settings:
+This test file calls `host.useSettings` to change the instance's settings, and passes only under the CLI:
 
 - `specs/features/native-modules/biometric-availability.e2e.ts`
 
-The CLI's `run` puts the instance on the declared settings before the file starts, and e2e alone does not. Run them through the CLI, for example `integration/expo-native/bin/control-clerk-expo run native-modules` from the repo root.
+The CLI holds the Platform API key that changes the settings, and it puts them back when the test ends. In a run by hand, `host.useSettings` fails, because e2e alone has no such key. Run it through the CLI, for example `integration/expo-native/bin/control-clerk-expo run native-modules` from the repo root.
 
 ## What a run by hand does not do
 
diff --git a/integration/expo-native/package-lock.json b/integration/expo-native/package-lock.json
index ddc3754da0a..32e7deae22c 100644
--- a/integration/expo-native/package-lock.json
+++ b/integration/expo-native/package-lock.json
@@ -6,7 +6,7 @@
     "": {
       "name": "verify-clerk-expo",
       "devDependencies": {
-        "@clerk/internal-mobile-e2e": "github:clerk/internal-mobile-e2e#928452603477b6b23b38714a0f88c279998dade2",
+        "@clerk/internal-mobile-e2e": "github:clerk/internal-mobile-e2e#6db71a0aaa96eb6436ee63104ad22a9a70ebf55d",
         "@types/node": "24.19.1",
         "typescript": "7.0.2"
       },
@@ -122,8 +122,8 @@
       }
     },
     "node_modules/@clerk/internal-mobile-e2e": {
-      "resolved": "git+ssh://git@github.com/clerk/internal-mobile-e2e.git#928452603477b6b23b38714a0f88c279998dade2",
-      "integrity": "sha512-IAv1CoFUre3sDLKXB+3HWc2jxtaL93K7tCFvuMR35/eh8ANkAWpiWqn+x3d4nauhoPdm4uC6E/Zd3nITU38q1w==",
+      "resolved": "git+ssh://git@github.com/clerk/internal-mobile-e2e.git#6db71a0aaa96eb6436ee63104ad22a9a70ebf55d",
+      "integrity": "sha512-3XTTA8cOTRZMVCwZMMWxzHVxMG1V0Lv22e5ZZmfZ7mOajWd8CMWdmt1qFMNdxyU8bfnsPhIELr3zte0wLa2v2A==",
       "dev": true,
       "dependencies": {
         "@e2e-dev/github": "0.4.0",
diff --git a/integration/expo-native/package.json b/integration/expo-native/package.json
index 640ea7bf340..69386e34d5f 100644
--- a/integration/expo-native/package.json
+++ b/integration/expo-native/package.json
@@ -7,7 +7,7 @@
     "typecheck": "tsc -p ."
   },
   "devDependencies": {
-    "@clerk/internal-mobile-e2e": "github:clerk/internal-mobile-e2e#928452603477b6b23b38714a0f88c279998dade2",
+    "@clerk/internal-mobile-e2e": "github:clerk/internal-mobile-e2e#6db71a0aaa96eb6436ee63104ad22a9a70ebf55d",
     "@types/node": "24.19.1",
     "typescript": "7.0.2"
   },
diff --git a/integration/expo-native/specs/features/native-modules/biometric-availability.e2e.ts b/integration/expo-native/specs/features/native-modules/biometric-availability.e2e.ts
index a8af2723009..347f4a0e9bd 100644
--- a/integration/expo-native/specs/features/native-modules/biometric-availability.e2e.ts
+++ b/integration/expo-native/specs/features/native-modules/biometric-availability.e2e.ts
@@ -6,6 +6,10 @@ test('useBiometricCredentials reports what the expo-biometrics native module fou
   screen,
   platform,
 }) => {
+  await host.useSettings({
+    config: { 'auth_biometric.used_for_sign_in': true },
+    environment: { 'auth_config.native_settings.trusted_device_sign_in_enabled': true },
+  });
   const nativeAnswer = platform === 'ios' ? 'biometric_authentication_unavailable' : 'no_local_credential';
   await host.launch();
   await host.tap(homeLinks(screen).nativeModules);
diff --git a/integration/expo-native/specs/features/native-modules/biometric-availability.settings.json b/integration/expo-native/specs/features/native-modules/biometric-availability.settings.json
deleted file mode 100644
index 1934771b5b1..00000000000
--- a/integration/expo-native/specs/features/native-modules/biometric-availability.settings.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
-  "config": { "auth_biometric": { "used_for_sign_in": true } },
-  "environment": { "auth_config.native_settings.trusted_device_sign_in_enabled": true }
-}
diff --git a/integration/expo-native/test/host.test.ts b/integration/expo-native/test/host.test.ts
index 928d0077a36..714cb76ccff 100644
--- a/integration/expo-native/test/host.test.ts
+++ b/integration/expo-native/test/host.test.ts
@@ -8,8 +8,6 @@ import { buildFixture, mustStep, nativeInputs, simulatorArch } from '../src/fixt
 import { host, metroPort, withCleanup } from '../src/host.ts';
 import { devClientEntry } from '../specs/app.ts';
 import { selectBackend } from '@clerk/internal-mobile-e2e/core/devices';
-import { resolveSpecs } from '@clerk/internal-mobile-e2e/core/e2e';
-import { STANDARD, declaredIn, planGroups, readSpecText } from '@clerk/internal-mobile-e2e/core/instances/settings';
 import { encodeLaunchArguments } from '@clerk/internal-mobile-e2e/specs/support/launch';
 import {
   VerifyFailure,
@@ -164,26 +162,6 @@ describe('the clerk-expo host', () => {
   });
 });
 
-describe('the committed specs of this repository', () => {
-  const dir = join(import.meta.dirname, '..');
-  const committed = resolveSpecs(dir, { all: true }).map(spec => ({ spec, ...readSpecText(dir, spec.path) }));
-
-  it('declare settings in one spec file, so a run of all of them is the standard group and then the biometric sign-in group', () => {
-    const declaring = committed
-      .filter(({ spec, ...text }) => declaredIn(text, spec.path) !== null)
-      .map(({ spec }) => spec.path);
-    assert.deepEqual(declaring, ['specs/features/native-modules/biometric-availability.e2e.ts']);
-    const plan = planGroups(committed, STANDARD.key);
-    assert.equal(plan.length, 2);
-    assert.equal(plan[0]!.settings, STANDARD);
-    assert.equal(plan[0]!.specs.length, committed.length - 1);
-    assert.deepEqual(
-      plan[1]!.specs.map(spec => spec.path),
-      declaring,
-    );
-  });
-});
-
 describe('metroPort', () => {
   it('gives every lane on the Mac its own port', () => {
     const ports = [