Debug mode injected fetch to 127.0.0.1:7772/ingest/… in my React app. After reproducing twice, debug-b473a1.log was never created. Shell POST to ingest worked, but browser logs did not (likely CORS from localhost:5000). Agent could not read runtime evidence and had to use console.debug + git instead. Is there a supported way to get browser debug logs into the workspace file?
Steps to Reproduce
Ask the agent to add debug instrumentation for a browser-based UI flow.
Hey, thanks for the detailed report. First, the main point: browser fetch → local ingest server → a file in the workspace is a supported flow, and it accepts cross-origin requests from a localhost dev server including localhost:5000. So CORS is most likely not the issue here.
The log is not written to the workspace root, it goes into the .cursor\ subfolder. First thing, check if the file exists here:
e:\dev\projects\...\.cursor\debug-b473a1.log
Then there are two possibilities:
File exists and it has content. This is a known issue we are tracking: the agent looks for the log via grep or glob, and those respect .gitignore. If your project .gitignore has *.log, the file becomes invisible to search even though it exists. I can’t share an ETA yet. Workaround: open .cursor\debug-<sessionId>.log, drag it into the context field as an @-mention, and press Enter instead of clicking Proceed. That way the agent will definitely receive the contents.
The file is missing or empty. In that case, the instrumented fetch() likely didn’t run in the runtime yet. With Node and TS runtimes using HMR, this can happen if the task starts before the dev server fully reloads with the instrumented code. Start the dev server, wait for the full reload after instrumentation, and only then run your repro steps. A 204 response from the server only means it’s up and accepted the request, not that real events were written.
Great that you found the file and that @.cursor/debug-b473a1.log worked. That’s exactly the case I mentioned. The log gets written to .cursor\, but since that folder is in your .gitignore, the agent’s grep or glob can’t see it, so it looks in the workspace root instead.
The agent not finding the log under .cursor\ especially on Windows is an issue we’re tracking. I can’t share an ETA yet, but I’ll post in the thread if there’s an update.
For day-to-day options:
Paste @.cursor\debug-<sessionId>.log into the chat and press Enter instead of clicking Proceed. That’s the simplest path, and you’ve already confirmed it works.
Move your Vite middleware to the workspace root. That also works if you want to fully avoid .gitignore.