Vote on features you'd love to see. Share your ideas and help shape the future.
Submit IdeaI want cursor agent to see my ui so we can have a feedback loop with agent
I want cursor to see my website and feedback loop into the agent to fix ui faster
How use cursor AI in my programming (Python,Django,HTML,CSS,Tailwind,JavaScript,React) life?
The agent might say: Let's build it. npm run build - to which I can hit the run button. But, then it'll say: Oh, we're no in the correct directory, let me try again. Wastes 30-60 seconds.
Overview: I’d love to suggest a powerful new feature for Cursor: a collaborative multi-agent system within the IDE. Rather than having just one AI agent assisting the user, this concept introduces a team of three AI agents who work together in real-time to build, test, and iterate on software projects. This structured collaboration mimics how real-world dev teams operate and could significantly improve efficiency, accuracy, and code quality. 👥 Agent Roles The system would consist of three distinct AI agents, each playing a specific role: Agent A – Lead Developer (Model A, e.g., Claude 4): Focuses on core logic and backend development. Writes modular, clean, and testable code based on project specs. Agent B – Co-Developer & Reviewer (Model B, e.g., Gemini 2.5 Pro): Works in parallel, handling complementary tasks (frontend, integration, or database layers), while reviewing and challenging Agent A’s work to ensure best practices, better architecture, and resilience. Agent C – Project Manager (e.g., GPT-o3): Orchestrates the workflow, breaks down tasks, tracks completion, prioritizes subtasks, and handles conflict resolution between Agent A and B. Also monitors code quality, ensures testing coverage, and initiates integration. Virtual Sandbox Environment To enhance safety and testing capability, agents should collaborate inside a lightweight sandboxed runtime environment: Allows the agents to run, test, and debug the app internally without affecting the user’s actual system. Could be a virtual container or ephemeral VM-like workspace that resets after each session. Supports test suites, unit/integration testing, and even CLI-based builds. This gives agents the freedom to experiment, fail fast, iterate, and verify everything in isolation before presenting finalized code to the user. request Usage Tradeoff Cursor's current premium tier provides ~500 AI prompt credits/month, with each AI operation consuming a credit. It’s clear that a tri-agent mode would consume 3x more tokens per action, but the benefits may outweigh the cost: Drastically reduced development time (from hours to ~30–60 minutes for medium-sized features). Higher-quality output, due to internal debate, testing, and review cycles. Improved user experience, especially for larger, multi-component applications. Users could toggle between Single-Agent Mode (default) and Multi-Agent Mode, allowing them to scale AI usage based on project complexity and budget. Benefits & Vision Better Parallelization: Work is split efficiently among agents. Less Manual Oversight: The user can delegate entire modules to the agents and focus on reviewing results. Advanced Collaboration: Simulates real-world dev team structures, perfect for fast prototyping or startup-style workflows. Customizable Agents: Future versions could let users assign different models or personalities to agents (e.g., strict reviewer vs. experimental coder). Conclusion Cursor is already an amazing platform for AI-driven development. This proposed Multi-Agent Collaboration Mode would push it to the next level enabling truly autonomous team workflows, accelerated development, and smarter problem-solving. Thank you for considering this feature. I believe it could become one of Cursor’s most innovative additions and a major differentiator in the AI coding space.
Problem / context When you run several agents in parallel or across a day, the default names do not tell you what each thread is doing. Renaming manually works, but it is slow and easy to skip. That adds friction right when you are trying to stay in flow. Teams and power users often want names that reflect work context, for example a Jira key, a repo or area name, the model in use, or a short project label. Today that usually means stopping to edit the title after the fact. Proposed solution Add an optional behavior (toggle in settings) so Cursor can suggest or apply an agent title from the initial user prompt and light metadata, for example: Extract a ticket id when present (e.g. PROJ-1234) Prefer a short headline from the first line or first sentence, capped for length Optionally append model or mode when it helps disambiguation (e.g. PROJ-1234 · Sonnet) Why it matters This reduces a small repeated tax on every agent session. It makes the agent list scannable at a glance, improves orientation when you return after a break, and scales better for anyone juggling multiple tasks, models, or clients without extra housekeeping.
Problem / context The usage dashboard is useful for totals, but each row is often just date, model, and token count. If you run several similar requests with the same model around the same time, rows blur together. You cannot reliably tie a line item back to a specific prompt, agent action, or experiment. That blocks honest answers to simple questions. Which run was expensive? Which prompt variant was this? Did that refactor attempt spike tokens? Proposed solution Augment each usage row with at least one stable, user-visible identifier and an optional label, for example: Request id (opaque, copyable) shown in the dashboard and optionally in the IDE for the session that created it Optional short label derived from the first user message, or user-editable at send time for experiments Optional link or deep link back to the chat or agent session when retention policy allows
Bring back the easily-accessible editor/agent switch; they WERE just exposed to the user, but the 2.0 update hid something broadly analogous to them behind a tiny button. Furthermore, the change was made with the promise of customisability, but the Agent/Editor/Zen/Browser modes hidden behind the tiny 'Change Layout' button just use... presets? That we can't reconfigure? Why do the sidebars switch sides between Agent/Editor mode?
When using Cursor Agent, many users write prompts in their natural language or with grammatical mistakes. Because of this, Cursor sometimes misunderstands the actual intention and performs the wrong task, gives incomplete output, or requires multiple follow-up prompts before achieving the desired result. This becomes time-consuming and frustrating, especially for non-native English speakers or users who are not experts in prompt engineering. Proposed Feature Add an “Auto Correct Prompt” or “Improve Prompt” option near the Agent and Auto controls in the chat input area. How It Would Work User writes a prompt normally. User clicks the Auto Correct Prompt button. Cursor automatically: fixes grammar, improves clarity, restructures the request, understands the intended task better. The improved prompt is shown to the user before sending. User can: accept it, edit it, revert to original prompt. Benefits Reduces repeated prompting. Saves time. Helps non-native English speakers. Improves Agent accuracy. Reduces misunderstandings. Makes Cursor easier for beginners. Helps users get correct results in a single prompt. Optional Enhancement Cursor could also show: “Original Prompt” “Improved Prompt” “Why this was improved” This would help users learn better prompting over time. Example: Original: “make this api work but not deleting old thing and check frontend issue” Improved: “Fix the API integration issue without removing existing functionality. Also investigate and resolve the related frontend issue while preserving current behavior.” This feature would greatly improve productivity and user experience inside Cursor.
Currently, when you define your perfil, only can select Spring Boot as Java framework but in Java space exist other popular frameworks like Quarkus & Micronaut.
## Summary Add a setting (e.g. **"Store chat history in workspace"**) so that chat/agent history is saved inside the workspace folder (e.g. in `.cursor/` or a user-configurable path) instead of only in `User/workspaceStorage` under App Data. ## Problem I work on the same projects from **two different PCs** and sync everything (including the workspace) via **OneDrive**. My code and project files are available on both machines, but **Cursor chat history is not**, because it is stored in: - `%APPDATA%\Cursor\User\workspaceStorage\<workspace-id>\state.vscdb` That path is **outside** the project and is **machine-specific**, so it does not get synced with the workspace. As a result, I lose context and previous conversations when I switch PCs. ## Proposed solution - **Setting:** e.g. `"cursor.chat.storeInWorkspace": true` (or a similar name). - **Behavior when enabled:** Store the workspace’s chat data (e.g. `state.vscdb` or equivalent) inside the workspace folder, for example: - `.cursor/workspaceStorage/state.vscdb`, or - A path configurable via settings. - **Optional:** Add `.cursor/` (or the chosen folder) to the default ignore list for version control so chat DBs are not committed unless the user wants to. ## Benefits - **Multi-machine workflow:** Users who sync the workspace (OneDrive, Dropbox, Google Drive, etc.) get the same chat history on all machines. - **Backup:** Chat history is backed up with the rest of the project. - **Portability:** Moving or cloning a project preserves its AI conversation history. - **Optional:** Still allow the current behavior as default for users who prefer not to store chat inside the project. ## Use case - Developer using two (or more) PCs. - Workspace and projects synced via OneDrive (or similar). - Need the same Cursor chat/agent history on both sides without manual copying of `state.vscdb`. Thank you for considering this.