Your workspace is set to 'x'. Lua language server refused to load this dir.

[leet0rz]

How are you using the lua-language-server?

NeoVim

Which OS are you using?

Windows

What is the issue affecting?

Other

Expected Behaviour

For this error not to occur, everything else is working just fine.

Actual Behaviour

LSP[lua_ls] Your workspace is set to `C:\Users\waffle`. Lua language server refused to load this directory. Please check your configuration.[learn more here](https://github.com/LuaLS/lua-language-server/wiki/FAQ#why-is-the-server-scanning-the-wrong-folder)

error is occuring even though the LSP works just fine and has been working for years prior to this with the exact same setup with no problems. Not sure what happened here but this error comes up, I remove it and everything is back working like normal. Only happens in the home dir.

Reproduction steps

1. Install neovim and luals, open neovim from home path and this error comes up.

Additional Notes

No response

Log File

No response

[sumneko]

Add --force-accept-workspace

[leet0rz]

Add --force-accept-workspace

This is the template for lua_ls in neovim, where exactly do I add it? Thanks!

require'lspconfig'.lua_ls.setup {
  on_init = function(client)
    if client.workspace_folders then
      local path = client.workspace_folders[1].name
      if vim.loop.fs_stat(path..'/.luarc.json') or vim.loop.fs_stat(path..'/.luarc.jsonc') then
        return
      end
    end

    client.config.settings.Lua = vim.tbl_deep_extend('force', client.config.settings.Lua, {
      runtime = {
        -- Tell the language server which version of Lua you're using
        -- (most likely LuaJIT in the case of Neovim)
        version = 'LuaJIT'
      },
      -- Make the server aware of Neovim runtime files
      workspace = {
        checkThirdParty = false,
        library = {
          vim.env.VIMRUNTIME
          -- Depending on the usage, you might want to add additional paths here.
          -- "${3rd}/luv/library"
          -- "${3rd}/busted/library",
        }
        -- or pull in all of 'runtimepath'. NOTE: this is a lot slower and will cause issues when working on your own configuration (see https://github.com/neovim/nvim-lspconfig/issues/3189)
        -- library = vim.api.nvim_get_runtime_file("", true)
      }
    })
  end,
  settings = {
    Lua = {}
  }
}

[tomlau10]

--force-accept-workspace is a launch cmd argument: https://luals.github.io/wiki/usage/#--force-accept-workspace

I don't know much about neovim, but according to the nvim-lspconfig's doc: https://github.com/neovim/nvim-lspconfig/blob/master/doc/configs.md#lua_ls

The default cmd assumes that the lua-language-server binary can be found in $PATH.
Default config:

• cmd :

{ "lua-language-server" }

maybe you have to this flag to the cmd?

require'lspconfig'.lua_ls.setup {
  cmd = { "lua-language-server", "--force-accept-workspace" },
  on_init = function(client)
    ... -- your original code above
  end,
  settings = {
    Lua = {}
  }
}

[leet0rz]

--force-accept-workspace is a launch cmd argument: https://luals.github.io/wiki/usage/#--force-accept-workspace

I don't know much about neovim, but according to the nvim-lspconfig's doc: https://github.com/neovim/nvim-lspconfig/blob/master/doc/configs.md#lua_ls

The default cmd assumes that the lua-language-server binary can be found in $PATH.
Default config:

• cmd :

{ "lua-language-server" }

maybe you have to this flag to the cmd?

require'lspconfig'.lua_ls.setup {
  cmd = { "lua-language-server", "--force-accept-workspace" },
  on_init = function(client)
    ... -- your original code above
  end,
  settings = {
    Lua = {}
  }
}

Thanks for answering! I tried to add --force-accept-workspace but the message seems to persist. Not entirely sure what's going on as I don't see the message anywhere other than in ~ dir with lua files.

[tomlau10]

I don't see the message anywhere other than in ~ dir with lua files.

By looking into the source code of luals, this error msg is generated during the workspace init logic, when the workspace path is / or ~ without setting the force accept workspace flag:

lua-language-server/script/workspace/workspace.lua

Lines 46 to 54 in cdb1b09

	--- 初始化工作区
	function m.create(uri)
	log.info('Workspace create: ', uri)
	local scp = scope.createFolder(uri)
	m.folders[#m.folders+1] = scp
	if uri == furi.encode '/'
	or uri == furi.encode(os.getenv 'HOME' or '') then
	if not FORCE_ACCEPT_WORKSPACE then
	client.showMessage('Error', lang.script('WORKSPACE_NOT_ALLOWED', furi.decode(uri)))

I guess this logic is to prevent LuaLS preloading too much files, because by default LuaLS will load every files recursively under root workspace path.

---

I tried to add --force-accept-workspace but the message seems to persist.

Anyway I tried to add a log.info("FORCE_ACCEPT_WORKSPACE", FORCE_ACCEPT_WORKSPACE) there to see its value when I specify a --force-accept-workspace flag, and to my surprise a nil is logged... 🙄

There is another bug 🐛

By further debugging, seems that the arg parsing pattern in the main.lua logic has a bug:

lua-language-server/main.lua

Lines 20 to 28 in cdb1b09

	local function loadArgs()
	---@type string?
	local lastKey
	for _, v in ipairs(arg) do
	---@type string?
	local key, tail = v:match '^%-%-([%w_]+)(.*)$'
	local value
	if key then
	value = tail:match '=(.+)'

• The ([%w_]+) pattern can only match flags with underscore _ but not a dash -
• i.e. it can match --force_accept_workspace and set the value into _G["FORCE_ACCEPT_WORKSPACE"]
• but (currently) cannot match --force-accept-workspace ... 🤦‍♂️

The workaround

Try to use --force_accept_workspace for now @leet0rz
I can log the value of FORCE_ACCEPT_WORKSPACE when I specify this flag

---

cc @sumneko

main.lua 中解析 arg 所用的 pattern 似是有 bug.

• '^%-%-([%w_]+)(.*)$' 只能 match 到 --force_accept_workspace (underscore 版) 而不能 match --force-accept-workspace
• 因為 pattern 用了 [%w_]+
• 似是要改成 [%w_-]+

[leet0rz]

--force_accept_workspace

It did not work initially but then I updated lua_ls and now that command you gave me the last time worked, thanks :)

[leet0rz]

@tomlau10

There seems to be a side-effect, now the server scans the home dir and apparently it's not suppose to do that and I am getting a different error message about scanning too many files and files being to big etc. Is there another or better solution here for me? I have default settings for neovim mostly so I would guess this would be the case for others too? As said before this never happened before and all of a sudden it started happening with no changes in my config. Maybe from a update of either neovim or lua_ls.

[tomlau10]

There seems to be a side-effect, now the server scans the home dir and apparently it's not suppose to do that

You're right, this warning exists because luals thinks that it will scan too much file, but adding --force_accept_workspace is just silencing this warning, as said in my previous comment.

As said before this never happened before and all of a sudden it started happening with no changes in my config.

I git blamed the relevant code:

lua-language-server/script/workspace/workspace.lua

Lines 46 to 56 in cdb1b09

	--- 初始化工作区
	function m.create(uri)
	log.info('Workspace create: ', uri)
	local scp = scope.createFolder(uri)
	m.folders[#m.folders+1] = scp
	if uri == furi.encode '/'
	or uri == furi.encode(os.getenv 'HOME' or '') then
	if not FORCE_ACCEPT_WORKSPACE then
	client.showMessage('Error', lang.script('WORKSPACE_NOT_ALLOWED', furi.decode(uri)))
	scp:set('bad root', true)
	end

• it's been there for 2 years 🤔
• without the --force_accept_workspace, luals will reject if your open / or ~/ as the workspace
• I have no idea why this never happened before and all of a sudden it started happening 😕😕

---

Install neovim and luals, open neovim from home path and this error comes up.

I am unfamiliar with neovim (I use vscode), but here are some questions/suggestions in my mind:

• May I ask why do you want to open home path as the root workspace at the first place?
  Since the logic of luals is to recursively scan all files in every sub directories in the root workspace
  if you open home path
  • then you will either get a warning;
  • or let it scan all files I guess?
• just say you have some reasons to open neovim from home path.
  • do you really need luals to run in this case?
  • maybe you can set some config to disable luals when you open home path?
    (but let it run in other cases)
• another idea is that maybe you can setup a .luarc.json in your home path with following

  {
      "$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",
      "workspace.ignoreDir": [
          "**/*"
      ]
  }

  • this let luals ignores everything such that it won't scan all your folders 🤔
    (you may change the ignore list accordingly)
  • and you keep the --force_accept_workspace option to silence the warning as well

---

Hope this can provide some insight on how to solve your problems 🙂 @leet0rz

[leet0rz]

@tomlau10 I am simply just opening .wezterm.lua - the config file for wezterm, not a project or anything like that. I am getting the warning that it is refusing because it's the home dir and if I add the force workspace setting it will give warnings that there are too many files being scanned or files being too big etc. Do you know if I can set that up inside the lsp settings instead of having a file? I tried to put it under workspace in the lsp and adding ignoreDir there but did not seem to be working.

[tomlau10]

I am simply just opening .wezterm.lua - the config file for wezterm, not a project or anything like that

I just find a relevant (?) FAQ: https://luals.github.io/wiki/faq/#why-is-the-server-scanning-the-wrong-folder

When a workspace is opened, the client will send the URI of the directory to be scanned. When you open a single file, the client is supposed to send null for the URI as there is no workspace, just a single file. However, some clients will mistakenly send the URI of the extension, or worse, the home directory. The server will do as it is told and scan what is sent, which can obviously cause issues should the home directory be sent.

There seems to be a single file mode? 🤔

Then I went to test with vscode:

• create a .wezterm.lua in my home director: C:\Users\TomLau
• use the open file to open the .wezterm.lua
  • nothing will be scanned from my C:\Users\TomLau (even though the file is in home directory)
  • the hover said only 12 files are cached (probably those built in meta files)
  • => so this works as expected ✅
• if otherwise I use open folder to open C:\Users\TomLau, then select .wezterm.lua from there
  • luals now starts to scan my whole home folder... 🙈 (because this is workspace mode I guess)

---

I think it's certainly related to your lua_ls plugin settings and how your plugin send to initialize request to server.
Again I am unfamiliar with neovim, maybe you have to ask help in the neovim community 🫠 .

From my side, I may try to setup a neovim editor with lua_ls to test this situation when I have time.

[tomlau10]

From my side, I may try to setup a neovim editor with lua_ls to test this situation when I have time.

I just setup neovim on my windows PC and configured luals with the template config provided here:
https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/configs/lua_ls.lua

And I can reproduce your situation that, opening a file in home folder will trigger scan all folders 😕

testing env: luals-3.15.3, neovim-0.10.3, nvim-lspconfig-1.3.0

• open a C:\Users\TomLau\test.lua
  ❌ soon will show warning "Preloaded files has reached the upper limit"
  and I notice the memory usage of luals exe is increasing continuously in task manager
• open a C:\Users\TomLau\test\test.lua (i.e. a file in an empty folder to test it)
  ✅ normal, memory usage is stable and no rapid increasing 🤔
  this is expected because the folder is empty
• open a D:\test.lua (I have many subfolders in D:\)
  ❌ memory usage is increasing rapidly, this suggests that luals and scanning all folders 😳

testing env: luals-3.9.3, neovim-0.10.3, nvim-lspconfig-1.3.0

I downgraded my luals to 3.9.3, which is a stable version that I used a while ago, then repeat all testing
The result are the same 🤔
=> so unrelated to luals I think

testing env: luals-3.15.3, neovim-0.10.3, nvim-lspconfig-1.0.0

Then I downgraded nvim-lspconfig to a version before you create this issue, which is 1.0.0
(I found it from release page: https://github.com/neovim/nvim-lspconfig/releases)

‼️ no more memory increasing ‼️
So the culprit must lie within the nvim-lspconfig 😳

git bisect result

I then do a git bisect on nvim-lspconfig (which is a git repo)

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
8d9fd3581ac07a2e1940435e13bda31a0cdeb795
2eccb418f2f972ad1167f8491a8180acdeb02384
We cannot bisect more!

• 8d9fd3581ac07a2e1940435e13bda31a0cdeb795 cannot be tested (error when launching nvim.exe)
• but clearly the refactor: use vim.lsp.start instead of vim.lsp.start_client neovim/nvim-lspconfig#3450 is causing this unknown scan all behavior when opening file in single file mode 😦
• I tested with latest master (339ccc81e08793c3af9b83882a6ebd90c9cc0d3b) as well and this issue persist

suggestions

• I suggest you to open issue in nvim-lspconfig repo: https://github.com/neovim/nvim-lspconfig
  (or search if there are already issues tracking this problem)
• If you decide to open a new issue in that repo
  you can also cross link to this issue here, to provide more context for nvim-lspconfig maintainer
• meanwhile you may try to downgrade your nvim-lspconfig to v1.0.0
  or any workable commit before that pr3450
  (say ac936a66fba9a58613bed95d7615cff2c5bf0387, as shown in my image above)

@leet0rz

I have default settings for neovim mostly so I would guess this would be the case for others too?

After going through the debugging above, I believe so.
A quick scan in nvim-lspconfig's issue page, seems nothing related to this issue.
Don't know why no one report it, maybe they don't know where to report to. 😂

As said before this never happened before and all of a sudden it started happening with no changes in my config.

The culprit PR neovim/nvim-lspconfig#3450 is merged on Nov 24, 2024, and you created this issue on Nov 30, 2024.
The time matches.
If you always pull the latest master of nvim-lspconfig, this explains that "all of a sudden it started happening with no changes in my (your) config 🙈

[tomlau10]

update

🤔 I believe this is a related issue: neovim/nvim-lspconfig#3531

• seems that now neovim is migrating the lspconfig setup to use vim.lsp.config() instead
• no more nvim-lspconfig plugin is needed, but you need the neovim preview version 0.11
• the example init.lua setup for luals: https://neovim.io/doc/user/lsp.html#lsp-quickstart

vim.lsp.config['luals'] = {
  -- Command and arguments to start the server.
  cmd = { 'lua-language-server' },
  -- Filetypes to automatically attach to.
  filetypes = { 'lua' },
  -- Sets the "root directory" to the parent directory of the file in the
  -- current buffer that contains either a ".luarc.json" or a
  -- ".luarc.jsonc" file. Files that share a root directory will reuse
  -- the connection to the same LSP server.
  root_markers = { '.luarc.json', '.luarc.jsonc' },
  -- Specific settings to send to the server. The schema for this is
  -- defined by the server. For example the schema for lua-language-server
  -- can be found here https://raw.githubusercontent.com/LuaLS/vscode-lua/master/setting/schema.json
  settings = {
    Lua = {
      runtime = {
        version = 'LuaJIT',
      }
    }
  }
}
vim.lsp.enable('luals')

With this setup, I can now open C:\Users\TomLau\test.lua as well as D:\test.lua, without the strange scan all folders issue.
And no more rapid memory increasing of luals exe now.

[leet0rz]

@tomlau10 very cool, that seems to be working so far, none of the errors are showing up and I can just place it right into my settings no issues so far. I'll message back if I find anything, strange that I am the only one reporting this, I wonder if this is happening with linux too or if it's a windows related issue and I guess not everyone is on nightly either but it is strange that I am the only person to be reporting this if that is the case lol. Maybe I can set up other LSPs like that too and just get rid of lspconfig, that would be nice.