I updated Cursor (now on Version: 3.5.33) and now @docs is completely gone. I also don’t see the list of documentation I’ve indexed in Cursor settings.
Was this feature removed? Please tell me no. This is/was one of Cursor’s killer features and I’d consider dropping it without this.
Hi @aslangoldenhour ,
It’s not available in the Agents window, but it should still be available in the Editor window. You can switch to the Editor window by going to File → Open Editor Window from the Agents view.
It is possible that we may deprecate the feature in the future, but right now from my side I’m seeing that we still support it in the Editor window.
Phew! I see that too now. PLEASE pretty please with sugar on top don’t depreciate this feature. 
haha. tbh it’s my favorite feature in Cursor other than Composer 2.5. Makes me sad that it isn’t in the agent window.
Hi @aslangoldenhour I just wanted to follow up here as I got a bit more clarity from the team. We are not currently planning to add @Docs support to the Agents window, so the best option for you is to continue to use it in the IDE view. 
Hi Cursor team,
Please bring back the @Docs and Indexing & Docs in the Settings page. I can’t seem to load it either in IDE or Agent window modes. That’s a very nice feature. Kindly bring it back if you can because it’s nice to index external docs that we’ve worked a lot to put into.
Thanks,
First the askQuestions tool stopped working, now the @docs, what’s next? I almost exclusively use the editor window and no docs are there anymore. I just don’t get, what is the purpose of removing features, that are (were) working perfectly. My humble, but proven opinion is, if something works perfectly and the users - we - aren’t complaining about it, the feature should definitely stay. It’s a shame that the best Cursor features are getting removed…
Hi @Peter_Sz Thanks for your post! The AskQuestion tool and the @docs are different cases. The AskQuestion tool is not available in the Cursor Grok 4.5 model, but we hope to bring it back to future models, as we know the community finds it useful. full thread here: Grok 4.5 cannot use AskQuestion tool; falls back to inline questions (Composer 2.5 works)
@docs has been removed, and we don’t have immediate plans to bring it back. For now, the closest options are keeping those docs as local markdown and `@`-mentioning the files, pasting a URL / using `@Web`, or putting standing guidance in project rules.
And just out of curiosity, since I think we, the subscribed (and even non-subscribed) users, have the right to know the reason of this decision. So what was the reason of removal? Because I just don’t get the reason behind it. Now we have to bring our own docs into codebase and mention it, instead of using a once, few days ago, working and fully functional feature…
The answer is essentially that agents are good enough now at finding the docs themselves. It’s no longer necessary to maintain that feature.
Documentation indexing was practically one of the main reasons for using Cursor IDE — and now it’s gone. On top of that, working with docs will now burn even more tokens.
Nice idea. Well done. You’re shipping regressions, not improvements.
Please upvote if this matters to you. Let’s show the Cursor team that this was a genuinely useful feature — one that clearly set Cursor apart from something like Claude Code.
Now that I have to ship my personal and project documentation link by link to add it to the workspace (which isn’t realistic—I don’t want to do that every time I work on a new or existing project),
or build an MCP that manages my documentation (at least then it becomes a one-time installation),
what differentiates this from using IDEs like Kimi Code, for example?
We’re not asking to improve the @Docs feature—only to bring it back to the IDE and let your developer subscribers do the work.
Hello, first time posting here though I probably should have posted earlier because of the direction Cursor is going.
As some other users have mentioned, the Docs-feature was one of the most important reasons I have continued on using cursor.
“agents are good enough now at finding the docs themselves”
What you are essentially saying here is “the user no longer needs a way to control based on WHAT the agent is building something”. With Docs I could have control over the material the agent is using to build my stuff.
“Give the agent a link then”, you might say. However, that means the agent has to go online and fetch that resource, when with docs it would be already indexed. For me this is stupid, and overlooking what many users want.
If you don’t want to give it to everyone for some reason I don’t understand, please give it to us as a plugin or something.
When I’m considering whether I’m going to use Cursor or not, taking into account the agents difficulties on following workflows, rules, skills, or what ever I want them to follow, NO DOCS means I’m going to need to consider ending my subscription. Too much is too much.
For example taking a look at the screenshot I pasted, the agents don’t care about following rules or anything, and they admit it. They waste tokens on how to go around my rules. They actively seek a way not to follow the instructions. Only way to get them to follow my rules is to enforce the rules with hooks.
So when it is so difficult to get you agent to do what I want, when I’m actually PAYING for it, and you take away one of the tools to control what the agent is doing, what’s the point on buying anything from you?
EDIT: The screenshot shows all admitted violations from ONE prompt.
I personally have not found this to be true.
I use many different models and each has it’s own set of rules as to when looking up documentation is necessary.
Most models trust their internal training data, and only look elsewhere if they don’t find anything.
My case is different.
I work with packages/libraries that are rapidly moving targets.
The training data may represent many different versions of a package and not capture that there are version differences.
Not uncommon for:
All that goes away when I provide (provided) the docs for the specific software version I am coding against.
Honestly, the biggest improvements in code quality I got out of agents happened when I gave it the docs I wanted it to use. The docs RAG system is (was) really good.
QUESTION:
Removal of this feature has me looking for a new tool to replace cursor.
Fable 5 is now unable to wrap its head around using supabase file storage buckets, whereas the exact same task and prompting last week resulted in in immediate build out of a service.
You shipped such regression that I am questioning if cursor is worth the $4000/mo I budgeted for it.
Forced to waste tokens on the agent using context7 now. Great.
It doesn’t work in “Editor” windows either.
Removal of this feature was a total mistake: it gives as reference the desire documentation instead of trusting the agent will find it by itself. It´s exactly one of the things make us choose Cursor as main dev tool.
Thumb down for the feature removal.
So when I tried to get an answer from you, you flagged my message and hide it?
Hi all, we appreciate you sharing your thoughts on this and understand the disappointment. Not every decision that we make is going to be popular, but it is in the service of moving the product forward. One of our core principles is to re-examine our features constantly and delete the ones that are no longer 1000% absolutely necessary. We recognize that in the process of doing this, features may be removed that were appreciated by users, and this may not be a popular decision, as it is in this case. But if we did not do this, we would not be able to innovate and push the product forward as rapidly as we do. It’s a tradeoff, but hopefully this helps add some context around why we removed it.
Would like to see more transparency, if possible, on how this is the case. Was it really a feature that required that much maintenance from the dev team?
In my opinion this is taking away one of Cursor’s main differentiator features above the competition.
@kevinn, since this is apparently where the @Docs discussion has moved, there is still a basic technical question Cursor has repeatedly declined to answer.
I asked it directly in the other thread:
Cursor initially said removing @Docs was “carefully considered.” When I asked whether token consumption had actually been compared, your response was that you had “not researched this topic extensively.” I have continued asking for an answer in that thread, but Cursor has stopped responding there while continuing to discuss the removal here.
So let’s ask it here.
This isn’t a question about whether Cursor needs to “move the product forward,” whether every feature must be “1000% absolutely necessary,” or whether users liked @Docs. Those are product philosophy arguments.
I am asking you a measurable technical question about the replacement Cursor is telling customers to use. People in this thread are already reporting wasted tokens, repeated documentation retrieval, and worse results. I’ve experienced the same thing since upgrading.
If Cursor measured it, please provide the answer. If Cursor did not measure it before deciding @Docs was no longer necessary, please say that. But please stop avoiding the question. It’s very suss and leaves users with a very reasonable conclusion: removing @Docs pushes work that was previously handled by a persistent documentation index into metered agent activity, causing users to burn more tokens.
