A coding agent working in a React Native repository sees the app and little else. The backend usually lives elsewhere, as a dashboard, a separate repo, or knowledge in someone’s head. The agent then guesses, and guesses about auth, purchases, and secrets are expensive. Fix that by giving it four things inside reach: a short project file that states the rules, a typed contract for the API, a backend it can start locally, and narrow read-only tools for inspection.
This article is the framework-specific companion to backend context that keeps AI coding agents safe. It uses React Native and Expo examples, and it applies to any mobile stack.
What does an agent get wrong in a React Native repo?
The mistakes are predictable, because the client code makes some shortcuts look easy.
It puts a secret in the app. Variables with the EXPO_PUBLIC_ prefix are inlined into the JavaScript bundle, and Expo tells you not to store sensitive values in them. See Expo’s guide to environment variables. React Native’s security guidance warns about the same thing. An agent asked to “call the model API” may add the key where the code runs.
It trusts the client for access. “Show the premium screen if isPremium” is a one-line change in the app. The decision belongs on the server, as explained in why subscription entitlements belong on the server.
It edits a shape that old apps depend on. Renaming a response field compiles in the latest build and breaks every installed version. See mobile API versioning and migrations for old apps.
It invents backend behavior. If the agent cannot read how the backend works, it writes calls to endpoints that do not exist.
What should the project file say?
Most agent tools read a file at the repository root for standing instructions. The AGENTS.md convention is one open format, and Anthropic documents project memory files for Claude Code. Keep it short, factual, and current. For a React Native app with a backend, cover these points.
# Project rules
## Layout
- `app/` is the Expo Router app. `backend/` holds the server config and migrations.
## Commands
- `npm run backend:start` starts the local backend with seed data.
- `npm run backend:validate` checks the config and prints structured errors.
- `npm test` runs app and backend tests.
## Rules
- Never put secrets in `EXPO_PUBLIC_` variables or app code.
- Access decisions (sign-in, plan, ownership) are made on the server, never in the app.
- Never edit an applied migration. Add a new one.
- Keep API changes additive. Old app versions stay installed.
- Run `backend:validate` and the tests before you say a change is done.The file is a contract with the agent, not documentation for people. Every line should be something the agent would otherwise get wrong. Update it in the same commit as the rule it describes.
How do you give the agent a typed contract for the API?
An agent changes code safely when a mistake fails loudly. A typed contract does that for the client and server boundary.
- Describe the API in a schema, such as an OpenAPI document.
- Generate the TypeScript client from it, and commit the generated code, or generate it in a build step the agent can run.
- Make the build fail when the generated types and the app disagree.
Now a server-side rename breaks the app’s type check on the agent’s machine, not on a user’s phone. The agent reads the error, fixes the call site, and re-runs the check. The same applies to the database. Constraints and foreign keys reject invalid data regardless of which code wrote it, so keep them in the schema and not only in app code.
Make validation errors specific. “Field plan must be one of free, pro; got premium” lets an agent fix the problem unaided. “Bad request” does not.
How do you let the agent run the backend locally?
The strongest guardrail is a fast loop. If the agent can start the backend, load seed data, run a scenario, and read the result in a minute, it catches its own mistakes.
For a mobile app, that loop needs a few things.
- One command to start and reset the backend with known users in known states, for example one user per subscription state. Testing subscription states before a real purchase shows how to seed them.
- Simulated providers for sign-in, purchases, and push, so no real account or money is involved. Simulated events do not prove a real provider integration works, so keep a separate check against each provider’s test environment.
- Tests the agent can run for the rules that matter: ownership, plan limits, and idempotent handlers.
Never give an agent production credentials. Give it a development database user that can only touch the development schema, and keep anything that affects production behind a step a person approves.
Which tools should the agent have for inspection?
Instead of a shell and a database password, expose a few narrow tools. The Model Context Protocol is an open way to do that: a server offers named tools and read-only resources to a compatible agent. Good first tools for a mobile backend are read-only.
- Describe a table, and list the current config.
- Validate a config change and return structured errors.
- Show the migration a change would produce, without running it.
Add write tools later, each with a dry run that reports what it would do. Keep read and write tools separate, so permissions can differ. Check the protocol documentation for the current specification before you build against it.
What should you review in the agent’s diff?
Even with all of the above, review the parts that carry risk. A short checklist for a React Native change:
- No new secret in the app, and no new
EXPO_PUBLIC_variable holding anything sensitive. - No access decision that exists only in the client.
- No removed or renamed field in an API that installed apps call.
- Migrations written as SQL and reviewed, not applied implicitly. Row ownership enforced in the database, for example with row-level security.
- Push token and purchase handlers still idempotent. See push notification architecture for APNs and FCM.
How does this relate to Edict?
Edict is a mobile backend in development, built for developers who use coding agents. It is designed so an agent edits one configuration file, edict.yaml, and the planned business logic layer and database module turn declared rules and entities into the backend. The design includes structured validation errors, an MCP server, and a local backend with simulated providers for agents to work against. React Native and Expo are among the frameworks it is aimed at, but which SDKs ship first has not been decided. None of this is available today, and the design may change.
How it works describes the planned flow. For the provider-by-provider setup of an Expo app, read backend for an Expo app: auth, subscriptions and push.
Key takeaways
- A React Native repo hides the backend from the agent, so move the rules into a short project file it reads.
- Use a typed API contract and generated client so backend changes fail the app’s type check, not a user’s phone.
- Give the agent a one-command local backend with seeded users and simulated providers.
- Offer narrow, read-only inspection tools first, and add write tools with dry runs later.
- Review diffs for client-side secrets, client-only access checks, and breaking API changes.