Repository navigation
use with craftos-pc indexes PC root dir #2317
Description
How are you using the lua-language-server?
Visual Studio Code Extension (sumneko.lua)
Which OS are you using?
Windows
What is the issue affecting?
Other
Expected Behaviour
not index every file on PC by recursively going through root dir
Actual Behaviour
accepts / as valid workspace directory, causing every file on my PC to be indexed
the fix done for #2159 seems to be incorrect - it should not index every file on my PC if I have a CraftOS workspace open. if it can't support the virtual filesystem, it should just ignore it. instead the extension is completely unusable in this configuration when trying to use craftos remote, even with attempting to override the force-accept-workspace parameter to false on user-level in vscode preferences. (maybe this is ignored for some reason? it's defaulted to true so would make sense)
not sure if this is an issue to be made on the vscode-lua extension or the LSP itself!
Reproduction steps
- Use CraftOS-PC in a project, and connect to a remote computer in Minecraft
- With the vscode-lua extension enabled, watch as every Lua file on PC is indexed because the root dir for the VFS is technically /
Additional Notes
No response
Log File
No response
Activity
carsakiller commentedon Sep 9, 2023
So, opening a CraftOS workspace causes your computer to be scanned? I thought it already supported other schemes like
craftos-pc:, but maybe not? It may be that the language server is simply working off the path in the URI and is not receiving the contents of virtual file systems from VS Code.checkraisefold commentedon Sep 9, 2023
Yes, exactly - it works off the path in the URI and doesn't actually go through the VFS files. I'm not sure if the language server spec even supports virtual file systems or if it can be correctly implemented - if it can't be, I would much rather it just ignore the VFS (or there be a way for me to ignore it, since there doesn't seem to be a way to configure it as such) than index the whole PC.
carsakiller commentedon Sep 9, 2023
I have done some CC:Tweaked remote development stuff in VS Code as well, and as far as I remember, using my own custom scheme for the remote files meant they were not diagnosed. Like you said, though, it appears to not be supported by the protocol.
The language server should only be operating on allowed schemes, though.
checkraisefold commentedon Sep 10, 2023
The documentation is outdated. supportScheme was removed
lua-language-server/changelog.md
Line 196 in 16b9ce9
Seems like this caused a regression for this particular use-case!
checkraisefold commentedon Oct 1, 2023
I was able to hotfix it for my local use by basically locally re-adding supportScheme and checking the URI scheme against craftos-pc, but of course this isn't ideal for any updates of the extension. Root dir is not indexed after doing this.
As an aside, diagnostics.disableScheme may be a setting that could work around this issue, but I'm not quite sure.
MCJack123 commentedon Oct 2, 2023
Hi, I'm the dev of the CraftOS-PC extension. I have known about issues like this for a while, and have never supported using the LLS with the extension. But let me know if there's anything I can do to improve support, though it sounds like the LSP doesn't work with remote filesystems.
checkraisefold commentedon Oct 2, 2023
I think the easiest fix for this issue is just for the LSP to not index the VFS. The LSP won't work on files in the CraftOS PC. sure. but that means I can still use the LSP for the stuff I am developing without it scanning every Lua file on my PC. I think bringing back supported schemes or some other workaround will probably work best on the LSP side of things, not much you can do from your extension I think.
checkraisefold commentedon Jan 31, 2024
This is still an issue and a significant incompatibility.
jhammerberg commentedon Jun 19, 2024
I can confirm this is still an issue.
ignacypolak1 commentedon Jun 22, 2024
Hi, I fixed it temporarly with setting below (inside of my workspace.json in visual studio code):
Lua extension will still work inside of remote craftos directories and files, however autocompletion from ComputerCraft not. It's still better to use local folder in the same time, work there and eventually drag and drop files to craftos remote directory.
Questwalker commentedon Oct 14, 2024
The Lua extension by Tencent(Yes, I know..) seems to behave better than this extension, and faster too.
Language support won't work on any files within the Craft-OS folder itself, but it'll properly work with local files within the workspace, and transferring files between the them is simple enough, so I'll use that extension for now.
MisteryDuck commentedon Nov 11, 2024
still an issue and seems like a significant one. Can we maybe get a fix? Like a little one? Just a smidge of it? At least an ability to stop it from scanning the whole pc, maybe?
Luminisc commentedon Jul 29, 2025
Issue is still here :(
lisekilis commentedon Sep 15, 2025
The issue is still present
... the language server managed to scan the whole file system on my laptop ("only" 200k+ files) and found 9k+ issues inside of factorio... which was not what I was working on
krispyking24 commentedon May 9, 2026
still around
C2Gamser commentedon Aug 18, 2026
A workaround for this is to set your open directory to the data directory of craftos in the vscode settings. Sure you'll have a whole computers/ folder in there now, but you can directly edit those files instead of having to open the remote files which causes the issue.