Fix Bug
Workflow
Inspect the workspace before changing files.
- Run
git status --short and note existing user changes.
- Identify the project type and available test commands from files such as
package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml, Makefile, or project docs.
- Prefer the repository's documented commands over guessed commands.
Run tests first.
- Start with the narrowest relevant test command when the user names a feature, file, or error.
- Otherwise run the main test command for the project.
- If dependencies are missing or the test command is unclear, inspect configuration and choose the least surprising command. Ask the user only when no reasonable local command exists.
Analyze the failure.
- Read the first actionable error, stack trace, assertion diff, or compiler diagnostic.
- Trace from the failing test or call site into the implementation.
- Separate root causes from incidental noise such as formatting warnings or cascading errors.
Repair common problems automatically.
- Fix syntax errors, import or export mistakes, wrong paths, stale names, simple type mismatches, broken selectors, off-by-one logic, incorrect conditionals, async timing mistakes, missing null checks, and failed assertions where the intended behavior is clear.
- Keep changes minimal and consistent with local style.
- Add or adjust focused tests when the bug fix changes behavior and the project already has a test pattern for that area.
- Do not rewrite unrelated code or revert user changes.
Verify.
- Rerun the failing test first.
- Then run the broader relevant test command when practical.
- If verification cannot run, record the exact command and blocker.
Produce the patch.
- Show the changed files with
git diff --stat.
- Review
git diff before the final response.
- Summarize the root cause, the fix, and verification results.
Command Selection
Use these as fallbacks only when the repository does not document commands:
- JavaScript or TypeScript:
npm test, npm run test, npm run lint, or the package manager already used by the lockfile.
- Python:
pytest, python -m pytest, or project-specific tox/nox commands.
- Go:
go test ./....
- Rust:
cargo test.
- .NET:
dotnet test.
- Java:
mvn test or gradle test.
When a command fails because of sandboxing, network access, dependency installation, or permission limits, request escalation using the normal tool approval flow instead of silently skipping it.
Final Response
Lead with what was fixed. Include:
- Root cause in one short sentence.
- Files changed.
- Tests or checks run, including failures or blockers.
- Any remaining risk only if it matters.
1---2name: fix-bug3description: Run when the user says "fix-bug" or asks Codex to automatically debug failing code. First inspect the repository, run the relevant tests, analyze errors, repair common bugs with minimal code changes, rerun verification, and produce a patch-oriented summary.4---56# Fix Bug78## Workflow9101. Inspect the workspace before changing files.11 - Run `git status --short` and note existing user changes.12 - Identify the project type and available test commands from files such as `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `pom.xml`, `Makefile`, or project docs.13 - Prefer the repository's documented commands over guessed commands.14152. Run tests first.16 - Start with the narrowest relevant test command when the user names a feature, file, or error.17 - Otherwise run the main test command for the project.18 - If dependencies are missing or the test command is unclear, inspect configuration and choose the least surprising command. Ask the user only when no reasonable local command exists.19203. Analyze the failure.21 - Read the first actionable error, stack trace, assertion diff, or compiler diagnostic.22 - Trace from the failing test or call site into the implementation.23 - Separate root causes from incidental noise such as formatting warnings or cascading errors.24254. Repair common problems automatically.26 - Fix syntax errors, import or export mistakes, wrong paths, stale names, simple type mismatches, broken selectors, off-by-one logic, incorrect conditionals, async timing mistakes, missing null checks, and failed assertions where the intended behavior is clear.27 - Keep changes minimal and consistent with local style.28 - Add or adjust focused tests when the bug fix changes behavior and the project already has a test pattern for that area.29 - Do not rewrite unrelated code or revert user changes.30315. Verify.32 - Rerun the failing test first.33 - Then run the broader relevant test command when practical.34 - If verification cannot run, record the exact command and blocker.35366. Produce the patch.37 - Show the changed files with `git diff --stat`.38 - Review `git diff` before the final response.39 - Summarize the root cause, the fix, and verification results.4041## Command Selection4243Use these as fallbacks only when the repository does not document commands:4445- JavaScript or TypeScript: `npm test`, `npm run test`, `npm run lint`, or the package manager already used by the lockfile.46- Python: `pytest`, `python -m pytest`, or project-specific tox/nox commands.47- Go: `go test ./...`.48- Rust: `cargo test`.49- .NET: `dotnet test`.50- Java: `mvn test` or `gradle test`.5152When a command fails because of sandboxing, network access, dependency installation, or permission limits, request escalation using the normal tool approval flow instead of silently skipping it.5354## Final Response5556Lead with what was fixed. Include:5758- Root cause in one short sentence.59- Files changed.60- Tests or checks run, including failures or blockers.61- Any remaining risk only if it matters.
j945935cy