Skip to content

Provide Feedback

Your feedback and contributions help shape the future of AI-assisted development. Learn how to report issues, suggest features, contribute code, and help improve documentation.

  1. Search existing issues to avoid duplicates

  2. Verify the issue is reproducible

    • Try in a fresh environment
    • Disable extensions/plugins
    • Update to latest version
  3. Capture the diagnostics maintainers actually ask for

    • Cursor: grab a Request ID (Command Palette > “Report AI Action” or follow Getting a Request ID) plus the build from Help > About
    • Claude Code: run /debug to read the session debug log, then /status for version/model/account; attach /doctor output if it flags anything
    • Codex: paste codex --version and the relevant ~/.codex/config.toml block (model, approval_policy, sandbox_mode); type /status in the TUI to confirm the active model and writable roots
## Bug Description
[Clear, concise description of the issue]
## Steps to Reproduce
1. [First step]
2. [Second step]
3. [See error]
## Expected Behavior
[What should happen]
## Actual Behavior
[What actually happens]
## Environment
- Tool: [Cursor / Claude Code / Codex]
- Version: [e.g., Cursor 1.7, claude-code 2.x, @openai/codex 0.137]
- Model: [e.g., Opus 4.8, Sonnet 4.6, GPT-5.5]
- OS: [e.g., macOS 15.5]
- Diagnostics: [Cursor Request ID / Claude Code /debug log / codex --version + config]
## Additional Context
[Screenshots, logs, related issues]

Claude Code Bugs

  • In-tool (primary): /bug sends the conversation to Anthropic and can open a public GitHub issue
  • GitHub: anthropics/claude-code
  • Discord: #bug-reports channel

Codex Bugs

DO:

  • Explain the problem you’re trying to solve
  • Provide concrete use cases
  • Suggest implementation approaches
  • Link to similar features in other tools
  • Gauge community interest first

DON’T:

  • Demand immediate implementation
  • Duplicate existing requests
  • Bundle multiple features in one request
  • Assume your workflow is universal
## Feature Description
[What you want to add/change]
## Problem Statement
[What problem does this solve?]
## Use Cases
1. [Specific scenario 1]
2. [Specific scenario 2]
## Proposed Solution
[How might this work?]
## Alternatives Considered
[Other ways to solve this]
## Additional Context
[Mockups, examples, references]
  1. Official Channels

  2. Community Voting

    • Upvote existing requests
    • Comment with additional use cases
    • Share in social media for support

Fix Typos & Errors

  • Correct spelling/grammar
  • Fix broken links
  • Update outdated information
  • Clarify confusing sections

Add Examples

  • Real-world use cases
  • Code snippets
  • Screenshots/GIFs
  • Video tutorials

Translate Content

  • Translate to new languages
  • Review existing translations
  • Localize examples
  • Cultural adaptations

Create Tutorials

  • Step-by-step guides
  • Best practices
  • Workflow examples
  • Tips and tricks
  1. Fork the repository, then clone your fork

    Terminal window
    git clone https://github.com/<your-username>/cursor-and-claude-code-developer-toolkit
    cd cursor-and-claude-code-developer-toolkit
  2. Create a branch

    Terminal window
    git checkout -b docs/improve-setup-guide
  3. Make your changes

    • Follow style guide
    • Test all examples
    • Preview locally
  4. Submit pull request

    • Clear description
    • Reference issues
    • Screenshots if UI changes

Writing Style:

  • Clear and concise
  • Active voice
  • Present tense
  • Second person (“you”)

Technical Style:

  • Use code blocks with syntax highlighting
  • Include file paths and line numbers
  • Test all code examples
  • Provide both simple and advanced examples
  1. Read contributing guidelines

    • Check CONTRIBUTING.md
    • Review code style guide
    • Understand project structure
  2. Start small

    • Fix a bug
    • Improve tests
    • Enhance documentation
    • Then tackle features
  3. Communicate first

    • Discuss major changes
    • Get feedback on approach
    • Coordinate with maintainers

Good PR Checklist:

  • Descriptive title
  • Clear problem/solution explanation
  • Tests included
  • Documentation updated
  • Follows code style
  • Passes CI/CD checks
  • Addresses review feedback

PR Template Example:

## Description
[What does this PR do?]
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation
## Testing
[How has this been tested?]
## Checklist
- [ ] Tests pass
- [ ] Documentation updated
- [ ] Code follows style guide

Bug reports get tools fixed; shared workflows get the whole community faster. When a prompt, rule file, or MCP setup saves you real time, write it up.

  • Post the concrete artifact, not the takeaway. “I added a .cursor/rules/ file that pins our Drizzle conventions” beats “Cursor is great for databases” — paste the rule, the CLAUDE.md block, or the ~/.codex/config.toml snippet.
  • Channels: the Cursor forum, Claude Code Discussions, Codex Discussions, and social (#CursorIDE, #ClaudeCode, #OpenAICodex).
  • In-tool quality signals also count: Claude Code’s “How is Claude doing this session?” rating and Codex’s / feedback feed directly back to the teams shipping these tools.

Cursor Beta

Settings > Beta > set update frequency to Early Access.

  • Ships pre-release builds first
  • Pair with Help > About to report the exact build

Claude Code Beta

Terminal window
npm install -g @anthropic-ai/claude-code@latest
  • claude update keeps you on the newest release
  • File regressions with /bug so the transcript is attached

Codex Beta

Terminal window
npm install -g @openai/codex@latest
  • Run codex --version after updating
  • Try pre-release surfaces in the App’s settings

Pre-release builds break in ways stable builds do not — that is the point, and a clean regression report is the most valuable thing you can file:

  1. Pin the version that broke and the last one that worked (cursor --version, claude --version, codex --version). A version delta lets maintainers bisect instantly.
  2. Capture the diagnostic before restarting — Cursor Request ID, Claude Code /debug log, or Codex /status — because a fresh session often loses the failing state.
  3. Run pre-release builds in a sandbox or a throwaway branch, never against --dangerously-skip-permissions on production code, so an experimental agent can’t trash real work.

This guide itself is open for contributions:

  1. Fork the repository

    Terminal window
    git clone https://github.com/<your-username>/cursor-and-claude-code-developer-toolkit
  2. Make improvements

    • Fix errors
    • Add examples
    • Enhance explanations
    • Update for new features
  3. Submit changes

    • Create pull request
    • Explain improvements
    • Link to sources

Current priorities:

  • More real-world examples
  • Video tutorial scripts
  • Translations
  • Advanced use cases
  • Troubleshooting scenarios

Active contributors receive:

  • Contributor badges on forums
  • Credits in release notes
  • Early access to features
  • Direct communication with teams
  • Conference tickets (top contributors)

Your contributions are permanently recorded:

  • Git history
  • Contributors page
  • Release notes
  • Annual reports

The difference between a report that gets fixed and one that gets closed as “cannot reproduce” is almost always the diagnostic payload, not the tone. Lead with the artifact the maintainer needs:

  • Cursor: a Request ID ties your report to the exact model call on Cursor’s side. Without it, “the agent hallucinated a file” is unactionable; with it, support can trace the request. Capture it via Command Palette > “Report AI Action”.
  • Claude Code: run /bug while the bad behavior is still on screen so the transcript is attached automatically, or paste the trailing lines of /debug output. Note whether you were on --dangerously-skip-permissions or a hook fired, since both change behavior.
  • Codex: state the surface (App / CLI / IDE / Cloud), the model from /status, and your approval_policy / sandbox_mode. A workspace-write vs read-only sandbox often explains “it refused to edit my file”.

Cursor:

Claude Code:

Codex:

  • Critical bugs: 24-48 hours
  • Feature requests: Reviewed monthly
  • Documentation: 1-2 weeks
  • General feedback: Best effort

Thank you for helping make AI-assisted development better for everyone. The most useful thing you can do is file one well-diagnosed bug with a Request ID, /bug transcript, or codex --version attached — that is what turns a frustrating session into a fix.