FIELD TOOL / AI ERROR ATTRIBUTION

“Is this my bug or Codex?” is the wrong first question.

When an AI coding tool throws a weird error, the expensive move is arguing with the model in the same messy context. Use this packet to separate code failure, prompt failure, wrapper/IDE state, quota/billing, moderation, and platform behavior before burning more credits or changing production code.

The first job is attribution, not repair.

A platform error and a repo bug can look identical from inside a long agent session. Freeze the smallest repro and one falsifying check before you ask the agent to keep patching.

surface says where the error appeared: CLI, web, IDE wrapper, API, image, billing page.
repro says the smallest input that triggers it without secrets.
control_check says what would prove the same tool still works elsewhere.
cost_guard says when to stop before credits disappear.

Rule: never let an agent spend a second repair attempt until it has named which layer it is testing.

Copyable Codex / AI coding error attribution packet

Use this before asking whether the failure is you, Codex, the wrapper, or the platform.

1. SURFACE
- Tool/model shown in UI or CLI:
- Entry point: web / CLI / IDE extension / API / image tool / other:
- Exact visible error text, redacted:
- Timestamp and timezone:
- Did it consume credits/tokens/messages? yes / no / unknown:

2. TASK SHAPE
- What I asked it to do in one sentence:
- Was this code generation, explanation, refactor, image generation, deploy, auth, or billing?
- Files / repo / branch involved, if any:
- Data or prompt content that might trigger policy/moderation, redacted:

3. SMALLEST REPRO
- Minimal prompt or command that still fails:
- Same failure in a fresh session? yes / no / unknown:
- Same failure with a harmless toy input? yes / no / unknown:
- Same failure outside the wrapper/IDE? yes / no / unknown:

4. CONTROL CHECKS
Run only safe checks.
- Known-good prompt/command succeeds? yes / no:
- Tool status page / changelog checked? link/result:
- Local code test result, if this is a repo bug:
- Network/proxy/auth check, if relevant:

5. ATTRIBUTION GUESS
Mark one primary layer and one backup layer.
- my code / prompt ambiguity / context rot / wrapper or IDE / auth / quota-billing / moderation-policy / platform incident / unknown
- Evidence for primary layer:
- Evidence against it:

6. COST GUARD
Stop if:
- two fresh-session attempts fail the same way;
- credits/tokens are consumed without new evidence;
- the error involves billing/auth/account state;
- the next step would expose secrets, private data, or production access.

7. NEXT SAFE ACTION
Pick one:
- file a minimal bug report;
- wait/check status;
- reduce prompt/input;
- switch wrapper but keep same task;
- run local tests;
- ask a human/account owner;
- scope a paid diagnostic with this packet attached.

8. FINAL RECEIPT
- layer tested:
- command/prompt used:
- observed result:
- what changed, if anything:
- remaining unknown:
- next action:

Pair with context budget Need a scoped diagnostic?

Do not debug from the longest context.

Open a fresh run for attribution. Long sessions turn platform state, stale assumptions, and repo errors into one soup.

Separate wrapper from model.

If the IDE extension fails, test the CLI or web surface with a harmless toy request before changing project files.

Track credit consumption.

A one-line prompt that burns the same credits as a multi-file repair is a billing/plan question before it is a coding question.

Use one falsifying check.

If a known-good command works, the whole platform is not down. If a toy prompt fails too, stop blaming your repo.

Redact before sharing.

Error screenshots often contain account IDs, file paths, project names, or tokens. Share shape, not secrets.

Repair starts after attribution.

Once the layer is named, the next action is usually obvious: local test, wrapper reinstall, wait, smaller input, or account-owner escalation.