3 ms·
Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.
by hack1312 3mo ago
Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.
- romanovcode 3mo agoWe're back to autorun.exe times
- username135 3mo agoTime is a flat circle it seems
- nicman23 3mo agobut it is just a agents.md file lol
- mort96 3mo agoThis has nothing to do with any language model or agent, this is just traditional deterministic code in the Cursor program.
- himata4113 3mo agoLet me introduce you to jetbrains, vscode and nearly every other IDE that relies on an LSP. Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.
- andbartol 3mo agoBoth jetbrains and vscode ask you if you trust the project
- tjoff 3mo agoWhat repo-binary is executed for the LSP?
- DanielHB 3mo agoVSCode at least prompts you to trust the project folder before running anything, otherwise it will use a globally installed LSP.
- hack1312 3mo agoThere’s no trust system by default in Cursor because they ship that feature disabled. https://cursor.com/docs/agent/security#workspace-trust https://cursor.com/docs/agent/security#workspace-trust
- nextweek2 3mo agoIt isn't "a binary", it's git.exe (which has a very specific purpose). We are talking about an AI tool which wants to know the current state of the folder it is indexing, that's a reasonable thing for an AI to want to do. You then take the default of Windows execution order of: look for the executable in the current folder otherwise check the PATHs in order. This is a Windows security issue which has been around since day one. To me the App is preparing to do some work so it is more responsive to my requests. This is a classic trade off between security and performance, where the odds of a malicious virus being in the root of your project are very small if you are already taking best practices. Perhaps what we really need is Microsoft to change the execution order and that the maintainers of Git add a new feature where we can block executables being in the root of a repo (or in the whole of a repo). That would prevent every app having to make the same workaround, fix the issue upstream and you'll never have to think about it again.
- mort96 3mo agogit.exe is just a name. Cursor has no reason what so ever to assume that a random binary in a random repo is a legitimate git binary just because its name happens to be git.exe.
- wongarsu 3mo agoThe trivial fix is to execute not "git.exe" but "C:\Program Files\Git\bin\git.exe". With a configurable git binary Of course that then leads you down the rabbit hole of whether the llm should exectute a known-good ripgrep, tree, etc. instead of depending on PATH resolution