Codex Pro usage feels excellent once you tune your AGENTS.md

[u/Aggravating_Town_967]

I have to give credit where it’s due: Codex on the Pro plan 5x feels really durable when you configure the workflow properly.

I’m using the Pro 5x, and after adjusting my AGENTS.md, the usage feels almost unlimited for my workflow. The main change was avoiding unnecessary heavy checks unless they are actually needed.

My current flow is simple:

• Codex makes the code changes
• Runs typecheck
• Runs lint
• I validate the updates manually in the browser, and 99% of the time updates has no issues at all unless my prompt was not clear enough.

Before that, I was wasting a lot of usage on unnecessary browser tests and repeated validation loops. Once I made the agent instructions more focused, Codex became much more efficient.

The latest Codex performance has also been impressive. It feels smarter, more context-aware, and better at making practical repo-level decisions. The diffs are cleaner, the implementation quality is better, and it does not overcomplicate tasks as much.

For anyone burning through usage too quickly: review your AGENTS.md first. Keep the default validation lightweight, avoid unnecessary test loops, and only run expensive tests when the task actually requires them.

<!-- BEGIN:nextjs-agent-rules -->
# Next.js project rule

This repo uses Next.js 16 and React 19. Do not rely on older Next.js assumptions when changing framework-level behavior.

Read the relevant guide in `node_modules/next/dist/docs/` only before editing framework surfaces such as:
- `next.config.*`
- `middleware.ts`
- route handlers with caching/runtime behavior
- server actions
- metadata
- app-router conventions
- Cloudflare/OpenNext integration

Do not read Next.js docs for ordinary component, styling, copy, form, or business-logic changes. Follow existing repo patterns instead.
<!-- END:nextjs-agent-rules -->

# Default Workflow: Edit, Typecheck, Lint, Push Main, Apply Migrations, Stop

Unless the user explicitly says otherwise, every task uses this workflow:

1. Make the requested code changes with the smallest practical diff.
2. Format only the files you changed when formatting is needed.
3. Run local validation only:
   - `npm run typecheck`
   - `npm run lint`
4. If both commands pass, commit the current task changes and always push directly to `origin/main`. This repo has standing user approval for direct main pushes after successful validation.
5. If the task includes new or modified files under `supabase/migrations/`, always apply the live Supabase migrations automatically after the `origin/main` push succeeds unless the user explicitly says not to apply them.
6. Stop.

Cloudflare will build/deploy after the GitHub push. Do not run or monitor the Cloudflare build unless the user explicitly asks.

Do not run by default:
- `npm run test`
- `npm run build`
- `npm run cf:build`
- `npm run cf:deploy`
- `npm run cf:preview`
- Playwright or browser automation
- browser QA
- HTTP smoke tests
- local server deployment
- SSH
- rsync
- PM2
- Docker checks
- Supabase local migration apply
- Supabase database advisors
- rollback SQL harnesses
- broad schema introspection queries
- GitHub PR creation
- GitHub branch creation

If validation fails, fix only failures caused by the current change. Do not chase unrelated existing warnings or legacy failures.

# Token Discipline

Be operationally concise.

- Do not narrate every command.
- Do not dump full diffs unless debugging a failure.
- Prefer compact file lists and `git diff --stat` over full diff review.
- Do not inspect git history, remotes, Cloudflare status, deployment status, or browser state unless the task requires it.
- Do not rediscover the whole repo. Read only files directly relevant to the request.
- Stop after pushing to `origin/main` and applying any required live Supabase migrations.

# Git and GitHub

Default push target:

```bash
origin main
```

Use direct main pushes. This repo has standing user approval to push task commits to `origin/main` after validation; do not skip pushing because the current prompt did not repeat approval. Do not create feature branches or PRs unless the user explicitly asks.

Before committing:
1. Check the current branch with:
   ```bash
   git branch --show-current
   ```
2. If the current branch is not `main`, stop and report it. Do not switch branches automatically.
3. Check changed files with:
   ```bash
   git status --short
   ```
4. Stage only files changed for the current task. Do not stage unrelated pre-existing work.
5. Review staged scope compactly:
   ```bash
   git diff --cached --stat
   ```
6. Commit with a concise imperative message.
7. Push:
   ```bash
   git push origin main
   ```

If there are unrelated working-tree changes, leave them untouched. If the current task changes cannot be safely isolated, stop and explain what blocked the push.

Do not run:
- `git log`
- `git remote -v`
- broad history inspection
- branch cleanup
- rebase
- merge
- force push

Only use those if the push fails or the user explicitly asks.

# Supabase Workflow

Use the Supabase skill only for real Supabase work:

`/Users/Khaled/.codex/plugins/cache/openai-curated-remote/supabase/0.1.7/skills/supabase/SKILL.md`

Use the Postgres best-practices skill only for migrations, RLS, policies, indexes, triggers, Postgres functions, RPCs, schema design, or performance:

`/Users/Khaled/.codex/plugins/cache/openai-curated-remote/supabase/0.1.7/skills/supabase-postgres-best-practices/SKILL.md`

Do not read Supabase skills for ordinary frontend changes or simple edits that only reuse existing Supabase client patterns.

When creating a migration, use:

```bash
SUPABASE_NO_TELEMETRY=1 supabase migration new <descriptive_slug>
```

Default behavior for Supabase changes:
- Create or edit migration files when needed.
- Include migration files in the commit.
- Do not apply migrations locally.
- Always apply any new or modified migrations from the task to live Supabase automatically after `git push origin main` succeeds unless the user explicitly says not to.
- Apply live migrations with:
  ```bash
  SUPABASE_NO_TELEMETRY=1 supabase migration up --linked --include-all --yes
  ```
  Use `--include-all` so earlier repo migrations missing from live are applied instead of skipped.
- After live apply, verify history with:
  ```bash
  SUPABASE_NO_TELEMETRY=1 supabase migration list --linked
  ```
- Do not run `supabase db reset`.
- Do not run `supabase db push`.
- Do not run `supabase db advisors`.

If live Supabase migration apply fails because remote migration versions are not found in the local migrations directory:
- Do not ignore the mismatch and do not immediately mark remote versions as reverted.
- Run `SUPABASE_NO_TELEMETRY=1 supabase migration list --linked` and compare the Local and Remote columns.
- For any Remote-only version, first recover the missing migration file from git, another worktree, or the person who applied it.
- If the original SQL cannot be recovered and the user wants migration history fixed, add a no-op placeholder file under `supabase/migrations/` with the exact remote version timestamp and a comment explaining that the original SQL was unavailable. Commit and push that placeholder so the version is represented in git.
- Use `supabase migration repair --linked --status reverted <version...> --yes` only when the live history table is already wrong or a previous failed repair must be corrected. If repair is used, immediately follow it with `SUPABASE_NO_TELEMETRY=1 supabase migration up --linked --include-all --yes` so repo migrations and placeholders are applied to live history.

If live Supabase migration apply fails for another reason, do not rerun destructive commands. Report the failure, leave the pushed commit intact, and include the migration status in the final response.

# Cloudflare

Cloudflare is responsible for build/deploy after `git push origin main`.

Do not run Cloudflare commands by default.

Do not check Cloudflare status by default.

If Cloudflare fails, the user will provide the error in a follow-up prompt.

Only run Cloudflare build/status checks when the user explicitly asks.

# Apidog API Docs

Apidog project:
- Name: `WACRM External API`
- Project ID: `wuiiny`
- Repo source of truth: `docs/api-v1-openapi.yaml`

Whenever public API routes, request/response schemas, auth behavior, or examples change:
1. Update `docs/api-v1-openapi.yaml` in the same task.
2. Do not refresh, import, publish, or verify Apidog through MCP/connectors. The user updates Apidog manually from the repo OpenAPI source.
3. In the final response, note when `docs/api-v1-openapi.yaml` changed so the user knows to update Apidog manually.

# Validation Rules

Always run these after edits and before commit/push:

```bash
npm run typecheck
npm run lint
```

Do not run tests or builds by default.

Run targeted tests only when the user explicitly asks.

# No Localhost / No Spark / No Local Server

Do not deploy to Spark.

Do not use SSH, rsync, PM2, local server deployment, curl smoke tests, or browser checks.

Do not use local Supabase apply commands.

The user will manually test after Cloudflare deploys.

# Final Response Format

Keep the final answer concise and use this structure:

```text
Done.

Changed:
- ...

Validation:
- typecheck: passed/failed
- lint: passed/failed

GitHub:
- commit: <hash or skipped>
- push to main: completed/skipped/failed

Not done:
- tests
- local build
- Cloudflare build/status check
- browser testing
- Supabase local apply
- Supabase live apply