codex-expo-run-actions
$
npx mdskill add openai/plugins/codex-expo-run-actionsConnect Expo projects to Codex Run via local scripts and environment configs.
- Enables Expo CLI logs in Codex action terminals through project-local scripts.
- Depends on package.json, app configs, and .codex/environments/environment.toml.
- Validates Expo presence before generating safe run scripts with fallbacks.
- Delivers logs and build status directly within the Codex app interface.
SKILL.md
.github/skills/codex-expo-run-actionsView on GitHub ↗
---
name: codex-expo-run-actions
description: Wire Expo projects into the Codex app with project-local run scripts and .codex/environments/environment.toml actions. Use when the user wants the Codex app Run button, build/run actions, action buttons, or a stable Expo start/run workflow from Codex.
version: 1.0.0
license: MIT
---
# Codex Run Actions for Expo
Use this skill to connect an Expo project to the Codex app action bar.
The goal is one project-local script plus `.codex/environments/environment.toml`,
so the user can press `Run` in the Codex app and see the Expo CLI / Metro logs in
an action terminal.
## Workflow
1. Confirm the current workspace is an Expo app.
- Look for `package.json`.
- Look for `app.json`, `app.config.js`, `app.config.ts`, or `expo` in `package.json`.
- Do not wire the Codex action at a monorepo root if the Expo app is in a child package.
2. Discover the package runner.
- Prefer the package manager declared in `packageManager`.
- Otherwise infer from lockfiles.
- The generated run script should still have a safe fallback to `npx expo`.
3. Create or update `script/build_and_run.sh`.
- Use the reference file for the script shape.
- Default no-argument mode starts the Expo dev server: `expo start`.
- Keep the dev server in the foreground so the Codex action terminal owns logs and Ctrl-C behavior.
- Support optional modes for direct buttons:
- `--ios` starts Expo and opens iOS simulator.
- `--android` starts Expo and opens Android.
- `--web` starts Expo for web.
- `--dev-client` starts in dev-client mode.
- `--tunnel` starts a tunnel.
- `--export-web` exports web.
4. Write `.codex/environments/environment.toml`.
- Always add or update one primary action named `Run`.
- Wire `Run` to `./script/build_and_run.sh`.
- Add direct `Run iOS`, `Run Android`, `Run Web`, or `Run Dev Client`
actions only when the user asks for those buttons or the project clearly needs them.
- If the environment file already exists, update the existing matching action instead of duplicating it.
5. Use the action script as the default local run path.
- After wiring, run `./script/build_and_run.sh --help` or a short non-server mode if you need to sanity-check syntax.
- Do not start a long-lived Metro server during a setup-only task unless the user asked you to run the app.
## References
- `references/expo-run-button-bootstrap.md`: canonical Expo `script/build_and_run.sh` and Codex environment action examples.
## Guardrails
- Try Expo Go / `expo start` first; do not default the Codex Run button to `expo run:ios`, `expo run:android`, prebuild, or EAS Build.
- Do not wire cloud actions such as `eas build`, `eas submit`, or store deployment into Codex buttons unless the user explicitly asks and accepts the auth / time / cost tradeoff.
- Do not create a nested git repo.
- Do not put secrets in `.codex/environments/environment.toml` or in the run script.
- Do not background Metro from the run script; the action terminal should show the active server logs.
- Do not hard-code npm if the project uses pnpm, yarn, or bun.
## Output Expectations
When setup changes are made, summarize:
- the Expo app root you wired
- the run script path
- the Codex environment file path
- the actions added or updated
- how to launch the same path from shell
More from openai/plugins
- accessibility-and-inclusive-visualizationMake data visualizations accessible and inclusive. Use when the user needs chart or diagram accessibility guidance, text alternatives for complex visuals, color and contrast review, keyboard support, reduced-motion behavior for animation or parallax, or an accessibility QA workflow for exported figures, UML-like diagrams, and dashboards.
- agent-browserBrowser automation CLI for AI agents. Use when the user needs to interact with websites, verify dev server output, test web apps, navigate pages, fill forms, click buttons, take screenshots, extract data, or automate any browser task. Also triggers when a dev server starts so you can verify it visually.
- agent-browser-verifyAutomated browser verification for dev servers. Triggers when a dev server starts to run a visual gut-check with agent-browser — verifies the page loads, checks for console errors, validates key UI elements, and reports pass/fail before continuing.
- agents-sdkBuild AI agents on Cloudflare Workers using the Agents SDK. Load when creating stateful agents, durable workflows, real-time WebSocket apps, scheduled tasks, MCP servers, or chat applications. Covers Agent class, state management, callable RPC, Workflows integration, and React hooks. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.
- ai-elementsAI Elements component library guidance — pre-built React components for AI interfaces built on shadcn/ui. Use when building chat UIs, message displays, tool call rendering, streaming responses, reasoning panels, or any AI-native interface with the AI SDK.
- ai-gatewayVercel AI Gateway expert guidance. Use when configuring model routing, provider failover, cost tracking, or managing multiple AI providers through a unified API.
- ai-generation-persistenceAI generation persistence patterns — unique IDs, addressable URLs, database storage, and cost tracking for every LLM generation
- ai-sdkVercel AI SDK expert guidance. Use when building AI-powered features — chat interfaces, text generation, structured output, tool calling, agents, MCP integration, streaming, embeddings, reranking, image generation, or working with any LLM provider.
- aiq-deploy|
- aiq-research|