# Provide Feedback URL: https://developertoolkit.ai/en/resources/feedback/ Description: File Claude Code, Codex, and Cursor bug reports maintainers can reproduce, route feature requests and security issues, and report mistakes in this guide. A bug report for Claude Code, Codex, or Cursor gets fixed when it carries a minimal reproduction and the diagnostics each vendor asks for: `/bug` and a debug log for Claude Code, `/feedback` and `codex doctor --json` for Codex, and the build number for Cursor. Feature requests, security vulnerabilities, and corrections to this guide each have a separate channel. This page is for developers who hit a tool bug and for tech leads who decide what feedback leaves the company. You know the situation: the agent deleted a file it should not have touched, you filed "it broke my repo," and a week later the issue closed as "cannot reproduce." The report was missing a version, a log, and a reproduction someone else could run. ## What a reproducible bug report gets you - A two-minute routine that captures the right diagnostics for each tool before the failing state is lost. - Two copy-paste prompts: one that shrinks a failing session to a minimal reproduction script, and one that checks for duplicates and drafts the issue. - A way to prove the report is correct, and later that the fix works, without re-reading the whole session. - The exact controls a team uses to limit or turn off what `/bug`, `/feedback`, and session surveys send. - The right private channel for security issues, and the right channel for mistakes in this guide. ## Which channel does each tool use? Use the in-tool command first when it exists. It attaches the session context that a hand-written issue usually lacks. | Purpose | Claude Code | Codex | Cursor | | --- | --- | --- | --- | | Bug, in the tool | `/bug` (alias `/share`) or `/feedback` | `/feedback` ("send logs to maintainers") | No in-tool path verified; see the forum row | | Bug, public tracker | [anthropics/claude-code issues](https://github.com/anthropics/claude-code/issues) (bug template) | [openai/codex issues](https://github.com/openai/codex/issues) | The [Cursor community forum](https://forum.cursor.com) | | Feature request | GitHub issue, feature request template | GitHub issue, or upvote an existing one | The Cursor forum | | Security vulnerability | [Anthropic on HackerOne](https://hackerone.com/anthropic) | [OpenAI on Bugcrowd](https://bugcrowd.com/engagements/openai) | Email `security-reports@cursor.com`, per the [`SECURITY.md` in cursor/cursor](https://github.com/cursor/cursor/blob/main/SECURITY.md) | | Code contribution | No contributing guide in the repository | Not accepted ("We do not accept external code contributions or pull requests") | Closed-source | | Community help | [Claude Developers Discord](https://anthropic.com/discord) | The issue tracker | The Cursor forum | The Claude Code and Codex rows were checked on 2026-09-26 against Claude Code v2.1.283, codex-cli 0.157.1, and each repository's `SECURITY.md`, issue templates, and `docs/contributing.md`. Cursor's site could not be fetched from this environment on 2026-09-26, so the Cursor column rests on the forum and the `SECURITY.md` in Cursor's public cursor/cursor repository, and makes no claim about Cursor's own diagnostic docs. ## How do you file a bug report maintainers can reproduce? 1. **Capture the diagnostics before you restart anything.** A fresh session often loses the failing state, so collect these first. **Claude Code** In the session that misbehaved: ```text /status # version, model, account, connectivity /doctor # installation and configuration checkup; can fix what it finds /debug the Edit tool rewrote a file outside the working directory /export bug-session.txt ``` `/debug` turns on debug logging from that point and analyses the log, so it catches the next occurrence, not the one already past. To capture the whole run, relaunch in your terminal with a log file and reproduce: ```bash claude --version claude --debug-file ./cc-debug.log ``` From a shell, `claude doctor` runs the installation check without opening a session. Note whether a hook fired, an MCP server was involved, or you ran with `--dangerously-skip-permissions`, because each one changes behaviour. **Codex** In the TUI: ```text /status # session configuration and token usage /debug-config # config layers and where each requirement came from ``` Then, in your terminal: ```bash codex --version codex doctor --json > codex-doctor.json # redacted, machine-readable report ``` State the surface (CLI, IDE extension, desktop app, or cloud) and the permission settings in use. A read-only sandbox explains many "it refused to edit my file" reports before anyone reads a log. **Cursor** Record the exact Cursor build number and the time of the failing request, and include any request or error identifier Cursor shows you. Cursor is closed-source, so these details are what lets its team find the request on their side. Reproduce once more with extensions disabled. If the problem disappears, name the extension in the report. 2. **Shrink the failure to a minimal reproduction.** A maintainer runs a 20-line script; nobody replays your two-hour session. Ask the agent to build it in a scratch directory, not in the project where the bug happened. **Copy-paste prompt: turn a failing session into a minimal reproduction** ```text The previous turns show a bug in the coding agent itself, not in my code: the agent's edit to src/api/users.ts was applied to src/api/user.ts instead. In a new directory /tmp/agent-repro, build the smallest reproduction of this: 1. Create only the files needed to trigger it, with placeholder content. 2. Write REPRO.md with: exact steps, the prompt to paste, the expected result, and the actual result from this session. 3. Write check.sh that exits 1 while the bug is present and 0 once it is fixed, by inspecting the files on disk after the steps run. 4. Do not copy any code, secrets, hostnames, or customer data from this project. Stop after writing the files and list them. ``` 3. **Redact before anything leaves your machine.** Search the log, the export, and the reproduction for keys, tokens, internal hostnames, and customer data. When Claude Code writes a local feedback bundle, it redacts known API-key and token patterns; source code and file contents are always included as-is, so check them yourself. 4. **Search for duplicates, then draft the issue.** An existing issue with your extra evidence gets more attention than a new one that maintainers close as a duplicate. **Copy-paste prompt: dedupe and draft the issue** ```text Use the gh CLI to search open and closed issues in anthropics/claude-code for this bug: run `gh issue list --repo anthropics/claude-code --state all --search "" --limit 20` with two or three different keyword sets. If an issue matches, show it and draft a comment that adds only what is new: my version, the reproduction from /tmp/agent-repro, and check.sh output. If nothing matches, draft a new issue using the template sections below and the files in /tmp/agent-repro. Keep it under 300 words, one bug per issue. Do not post anything; print the draft for me to review. ``` Replace `anthropics/claude-code` with `openai/codex` for a Codex bug. For Cursor, run the same search on the forum by hand. 5. **File it, attaching the session where the tool allows it.** In Claude Code, `/bug` opens a consent screen where you choose how much history to include. In Codex, `/feedback` uploads logs, and you can decline the log upload and send only the note (codex-cli 0.157.1). Paste the issue link into your team's tracker so the workaround has an owner. Use this skeleton for the public issue. The Claude Code bug template also asks whether the bug is a regression and for the last working version, and makes you confirm you searched existing issues, filed a single bug, and run the latest version. ```markdown ## What happened The agent applied an edit meant for src/api/users.ts to src/api/user.ts. ## Reproduction Steps and prompt: see REPRO.md (attached). `check.sh` exits 1 on the affected version. ## Expected / actual Expected: edit lands in users.ts. Actual: user.ts is modified, users.ts is unchanged. ## Environment - Tool and version: claude --version / codex --version / Cursor build - Model and permission mode: from /status - OS and shell: - Diagnostics: debug log excerpt / codex-doctor.json / Cursor error or request identifier ## Last version that worked (if known) ``` ## How do you prove the report is right without re-reading the session? The `check.sh` from step 2 is the oracle. It turns "I think the agent did something odd" into a pass/fail signal that anyone can run, so neither you nor the maintainer has to re-read the transcript. - **Before filing:** run `check.sh` twice on the current version. It must fail both times. A reproduction that fails once in five runs is still useful, but say so in the issue. - **Across versions:** install the previous version, run the check, and put the result in the report. "Fails on 2.1.283, passes on 2.1.274" lets maintainers find the change quickly. - **After the vendor ships a fix:** upgrade, run `check.sh`, and remove your workaround only when it exits 0. Whoever owns the workaround in your tracker signs off on that result. - **In your own repository:** if the bug corrupted a file type, add a test or a lint rule that catches that corruption. That test keeps protecting you if the regression returns, even before the vendor responds. To learn the same oracle-first habit for application bugs, see [debugging with Claude Code](/en/claude-code/test/debugging/) and [bug hunting with Codex](/en/codex/test/bug-hunting/). ## How do you report a regression after an update? Regressions are the reports vendors act on fastest, because a version pair narrows the search. **Claude Code** Claude Code has two release channels. On 2026-10-17, `latest` is v2.1.302 and `stable` is v2.1.292 (npm dist-tags); `stable` is typically about a week behind and skips releases with major regressions. To confirm a regression, install the previous version and rerun the check. On a native install (the default), use `claude install` with a version number (checked on Claude Code v2.1.286, 2026-09-30): ```bash claude install 2.1.274 export DISABLE_AUTOUPDATER=1 # stops the background updater moving you back to latest claude --version # must print 2.1.274 before you trust the result ./check.sh; echo "exit: $?" ``` If you installed with npm instead, run `npm install -g @anthropic-ai/claude-code@2.1.274` in place of the first line. Do not mix the two: an npm install on a machine with a native install adds a second copy that `/doctor` flags, and it may not be the `claude` on your `PATH`. Confirm the version with `claude --version` before you run `check.sh`. `DISABLE_AUTOUPDATER=1` is documented in the Claude Code environment-variable reference (checked 2026-09-26); unset it when the test is done. To keep a team off fresh regressions, set `"autoUpdatesChannel": "stable"` in `settings.json` or through `/config`, and enforce it with [managed settings](/en/org/managed-policy/). **Codex** Pin the last version that worked and rerun the check: ```bash npm install -g @openai/codex@LAST_GOOD_VERSION codex --version && ./check.sh; echo "exit: $?" ``` Replace `LAST_GOOD_VERSION` with the version you ran before the update (`npm view @openai/codex versions` lists them). Return with `npm install -g @openai/codex@latest`. **Cursor** Record the build you were on before and after the update. If you run pre-release builds, reproduce once on a stable build before you file, and say which one you tested. Test pre-release builds in a throwaway branch or a disposable sandbox. Never combine a new build with `--dangerously-skip-permissions` or a full-access sandbox on a repository you care about. ## How do you write a feature request that gets triaged? The Claude Code feature request template opens with a **Problem Statement**: what you are trying to solve and why you need it. Codex's contributing guide asks for your use case, the behaviour you want, and why it would improve your workflow. Both reward the same shape: 1. **One request per issue.** The Claude Code template makes you confirm it is "a single feature request (not multiple features)." 2. **The problem before the solution.** "Hooks cannot see which subagent made the edit, so our audit log attributes every change to the parent session" is actionable. "Add subagent IDs to hooks" invites a debate about the wrong design. 3. **A concrete workflow.** Name the files, the commands, and the manual step the feature would remove. 4. **An upvote over a duplicate.** When an issue already exists, add a reaction and a comment with your use case. ## What does feedback send, and how does a team control it? Tech leads need this section before rolling a tool out. The Claude Code facts below come from its data-usage and environment-variable docs, checked on 2026-09-26. | Control | Claude Code | Codex | | --- | --- | --- | | What a report sends | The conversation, including code. You choose the current session (default) or also other sessions from the same project in the last 24 hours or 7 days | Logs, optionally with a `codex doctor` report attached; you can send the note without logs (codex-cli 0.157.1) | | Retention | Transcripts sent through `/feedback`, `/bug`, or `/share`: 5 years | Not stated in codex-cli 0.157.1 | | Turn the command off | `DISABLE_FEEDBACK_COMMAND=1` (older name `DISABLE_BUG_COMMAND` still accepted) | `[feedback]` `enabled = false` in `config.toml` (setting present in codex-cli 0.157.1) | | Session survey | "How is Claude doing?" records only the rating; `CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1` turns it off | — | | Claude-drafted feedback | Claude can queue feedback drafts that you review in `/feedback`; nothing is sent until you send a draft. Turn off with `"feedbackDrafts": "off"` in user or managed settings, or `CLAUDE_CODE_SEND_FEEDBACK=0` for one session; `DISABLE_FEEDBACK_COMMAND` also disables it | — | | Third-party providers | On a third-party provider (Amazon Bedrock, Google Cloud's Agent Platform (formerly Vertex AI), or Microsoft Foundry) or with no Anthropic credentials, the report is written to `~/.claude/feedback-bundles/` with known key and token patterns redacted; nothing leaves until you forward it | — | The survey can be followed by a separate question asking to upload the session transcript. Answering **Yes** uploads the conversation, subagent transcripts, and the session log, retained for up to 6 months. Nothing uploads unless someone selects **Yes**. For a team, decide the policy once: which tools may send transcripts, who reviews a report before it leaves for a regulated codebase, and where the setting is enforced. See [privacy and data handling](/en/org/privacy-data-handling/) for the policy and [managed settings](/en/org/managed-policy/) for enforcing it. ## Where do security vulnerabilities go? Never file a vulnerability as a public issue or through `/bug`. A public issue discloses it to everyone before a fix exists. - **Claude Code:** Anthropic's program on [HackerOne](https://hackerone.com/anthropic), linked from the repository's `SECURITY.md`. - **Codex:** OpenAI's program on [Bugcrowd](https://bugcrowd.com/engagements/openai), linked from the repository's `SECURITY.md`. - **Cursor:** email `security-reports@cursor.com`, as the [`SECURITY.md` in the cursor/cursor repository](https://github.com/cursor/cursor/blob/main/SECURITY.md) asks (checked 2026-09-26). Never post it on the forum. If an agent did something unsafe that is not a vulnerability, such as ignoring a deny rule you configured, that is a bug. File it through the normal channel with a reproduction. ## How do you report a mistake in this guide? The guides on developertoolkit.ai are not open source, so there is no pull request path. Use one of these instead: - **"Improve this page"**: the button beside every article opens an issue in the [public companion repository](https://github.com/mjaskolski/cursor-and-claude-code-developer-toolkit) with the page path already in the title. Say what is wrong, what is right, and link the source, for example a changelog entry or a `--help` output with its version. - **Email**: hello@developertoolkit.ai for anything else, or see the [contact page](/en/contact/). - **Discord**: the [community server](https://discord.gg/czS5bSapg9), where readers ask about the guides and feature requests are collected. A correction with a version-stamped source gets fixed fastest. "The `-a on-failure` value fails on codex-cli 0.157.1 with 'invalid value'" is easy to verify. "This is outdated" is not. ## What goes wrong when you report a bug? **Closed as "cannot reproduce."** The report described the symptom without a reproduction. Recover by adding `REPRO.md`, `check.sh`, and the version pair, then ask for the issue to be reopened. Do not open a second issue. **A secret went out in a log.** Rotate the credential first. Editing the issue afterwards does not help, because the original text may already be copied or indexed. Then edit the issue and tell the maintainers what was exposed. **`/bug` or `/feedback` does nothing.** Your organisation may have set `DISABLE_FEEDBACK_COMMAND` or `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC`, or you are on a third-party provider or have no Anthropic credentials, and the report was written to `~/.claude/feedback-bundles/`. Check with your admin before you forward the file. For Codex, check whether `feedback.enabled` is `false` in your configuration. **Your pull request to Codex was closed.** Codex does not accept external code contributions. Post your fix as a root-cause analysis on the issue instead. The Codex contributing guide lists that as the contribution it wants. **The bug only appears on `latest`.** Put the team on the `stable` channel, file the regression with the version pair, and switch back when `check.sh` passes on a newer release. **The issue goes quiet.** Neither repository's issue templates nor its contributing and security docs promise a response time (checked 2026-09-26). Add new evidence when you have it, such as another version that fails or a narrower reproduction. Do not post "+1" comments; a reaction does the same without notifying every subscriber. ## Where to go next with tool problems - [Troubleshooting guide](/en/resources/troubleshooting/): fixes for common Claude Code, Codex, and Cursor problems, which you should check before filing. - [Community resources](/en/resources/community/): forums, Discord servers, and channels where other users compare workarounds. - [FAQ](/en/resources/faq/): short answers about plans, models, and setup. - [Privacy and data handling](/en/org/privacy-data-handling/): the team policy for what leaves the company, including feedback transcripts.