What the agent does
For a React Native app like obytes/react-native-template-obytes, the agent starts with package.json, app.config.ts and the lockfile. The template is named obytesapp, packageManager pnpm@10.12.3, expo ~54.0.32 and react-native 0.81.5, with Expo Router, Jest (preset jest-expo), ESLint and Maestro flows under .maestro/. Scripts that define the quality bar are pnpm lint, pnpm type-check (tsc --noemit), pnpm test (jest) and pnpm check-all. app.config.ts builds an ExpoConfig from env.ts (name, scheme, slug obytesapp, newArchEnabled: true, EAS project id) and registers plugins such as expo-router, expo-splash-screen, expo-font and expo-localization.
The upgrade command is npx expo install --fix after aligning the expo package to the target SDK, then pnpm install so pnpm-lock.yaml matches. The agent reads Expo’s SDK changelog for breaking changes that touch app.config.ts, babel.config.js, metro.config.js or expo-router layouts under src/app. It does not run EAS cloud builds (build:production:ios and siblings) unless credentials exist; local proof is lint, type-check and Jest.
Tests in the tree are focused: login-form.test.tsx under src/features/auth and UI tests for button, input, checkbox and select under src/components/ui. The agent runs those via pnpm test and fixes compile breaks in application code caused by the SDK bump. A dependency that fails lint, type-check or test is reverted; the PR lists the attempted version and the failing command. Maestro e2e (pnpm e2e-test) is noted as optional when no simulator is attached.
Native prebuild directories are not committed unless the repo already tracks ios/ and android/. The agent prefers config plugins and lockfile changes. One pull request summarizes each successful bump on its own line.
Environment files follow env.ts and the EXPO_PUBLIC_* variables already named in app.config.ts. The agent does not invent new EAS profiles in eas.json or rotate the EAS_PROJECT_ID. When expo-doctor (pnpm doctor) reports a peer mismatch after the bump, that output is pasted into the PR description beside the line for the offending package.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Upgrade the Expo SDK to the latest compatible versions with npx expo install --fix, run pnpm lint, pnpm type-check and pnpm test, and open a pull request with one line per bump. Leave out any upgrade that breaks the build or tests and say why.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The pull request updates package.json, pnpm-lock.yaml and any config files the SDK requires (app.config.ts, metro or babel when the changelog demands it). The description lists each bump that passed pnpm lint, pnpm type-check and pnpm test, and each skipped bump with the error summary.
A reviewer confirms newArchEnabled and Expo Router entrypoints still type-check, that Jest tests under src/ still pass, and that no unrelated feature work landed. Session transcript and PR checks are available through GET /o/{org}/sessions/{id}.
Run it on every Expo SDK release
When Expo publishes a new SDK, enqueue one POST /o/{org}/sessions per mobile app repository with this prompt. Stagger starts to stay under the key’s max_concurrent limit.
Use webhook_url to collect finished runs. Merge or close each upgrade PR before scheduling the next SDK line on the same app so lockfiles do not race.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
Expo SDK upgrades pull a large peer set and often break TypeScript and Jest together. A Rush sandbox can apply expo install --fix, run the three pnpm checks and revert bad bumps without disturbing a developer’s local simulator install.
Parallel sessions across apps show which codebases move cleanly. The transcript keeps the exact expo and pnpm output for each attempt, which a green PR description alone does not.
Frequently asked questions
Does it require EAS credentials?
No for the default prompt. Proof is pnpm lint, type-check and test. EAS build scripts remain for humans or a follow-up that supplies credentials.
Will it commit ios/ and android/ prebuild output?
Only if the repository already tracks those folders and the SDK upgrade requires it. Config plugins and the lockfile are the preferred change set for an Expo CNG app.
What about Maestro flows?
pnpm e2e-test needs a device or emulator. The agent reports when Maestro cannot run and does not treat a missing simulator as a passed e2e suite.
Why pnpm and not npm?
package.json sets packageManager pnpm@10.12.3 and preinstall runs only-allow pnpm. The agent respects that pin and the existing pnpm-lock.yaml.
Does it touch React Navigation or Zustand stores?
Only when TypeScript or Jest failures after the SDK bump point there. Feature code under src/features stays unchanged if lint, type-check and test already pass with the new Expo peers.