Skip to content

Instantly share code, notes, and snippets.

@lucasecdb
Last active November 19, 2025 23:25
Show Gist options
  • Select an option

  • Save lucasecdb/2baf6d328a10d7fea9ec085d868923a0 to your computer and use it in GitHub Desktop.

Select an option

Save lucasecdb/2baf6d328a10d7fea9ec085d868923a0 to your computer and use it in GitHub Desktop.
Godot LSP with Neovim inside WSL

Godot workflow with Neovim and WSL

Note

Since writing this guide, me and a few other users have found that using the Godot LSP directly from Neovim wasn't working as well as it could be. This is mostly due to the Godot LSP running on Windows expecting Windows paths in the LSP messages (such as C:\Users\user\MyGame\script.gd), but our LSP client sends (and also expects to receive) paths on a Linux format (e.g. /mnt/c/Users/user/MyGame/script.gd).

This caused several functionalities from the LSP to not work, and some errors to appear in the editor that weren't actual issues. To fix this, I published a very small LSP server, godot-wsl-lsp, that serves to bridge this gap and provide a better DX. It is highly recommended to use it instead of the setup described here, although it is still important to follow some of the steps. Please check the README on the LSP repository for more information.

There already are a few good blogposts regarding integrating Neovim and Godot, including how to setup its LSP server with Neovim builtin client. But none of them goes into detail into how integrate them if you are running Neovim inside Windows Subsystem for Linux, which some people would prefer, myself included.

I just wanted to provide some additional guidance, and how to integrate them with Windows.

The posts that were most relevant to accomplish this final results were:

The first guide will only teach how to setup Neovim in WSL to work as an external editor to Godot. Although it uses a obsolete program called nvr, which features have already been integrated in Neovim itself, check the remote docs. You can use the nvim.cmd batch program, which has been updated to use the builtin flags on nvim. On Godot, you need to set the Exec flags as {file} {line} {col}.

The second post will explain how to integrate Godot LSP with Neovim, but they assume you are running both on the same environment (either Neovim running on Windows, or both running on Linux, for example).

The third one one explains how to access Window's localhost network from within WSL.

And the last one will explain how to bypass Windows firewall for connections coming from WSL.

The major issue is that localhost inside WSL is a separate network from Windows localhost, and we need to create a firewall rule to enable Neovim inside WSL to communicate with Godot LSP (which runs on Windows).

Note

This should only be necessary if you are not using WSL 2, in which you can set mirrored networking and would be able to access Windows' localhost without any of these firewall rules.

You can run this Powershell command (found in the superuser post's answer) in Windows to create this firewall rule:

New-NetFirewallRule -DisplayName "Godot LSP" -Direction Inbound -Protocol TCP -LocalPort 6005 -Action Allow 

I removed the -InterfaceAlias to allow any network interface to communicate with Godot LSP. You can also create another rule to access Godot's DAP as well

New-NetFirewallRule -DisplayName "Godot DAP" -Direction Inbound -Protocol TCP -LocalPort 6006 -Action Allow

These ports are configurable inside Godot, if you want to assign them to a different value. Look into Editor > Editor Settings > Network > Language/Debug Adapter. You will also need to set the "Remote Host" in the Language Server to 0.0.0.0.

Then, you should restart your computer for the firewall rules to take an effect, and then copy paste the gdscript.lua to ~/.local/nvim/after/ftplugin/gdscript.lua (inside WSL).

Now, you should have the server start everytime you open a GDScript file inside your Neovim instance in WSL, while Godot is running on Windows. Remember to always run neovim with the following command nvim --listen /tmp/godot.pipe.

-- after/ftplugin/gdscript.lua
local uv = require("luv")
local hostname = vim.fn.hostname() .. '.local'
local ip_address = uv.getaddrinfo(hostname)[1]['addr']
local port = os.getenv('GDScript_Port') or '6005'
local cmd = vim.lsp.rpc.connect(ip_address, port)
local pipe = '/tmp/godot.pipe'
vim.lsp.start({
name = 'Godot',
cmd = cmd,
filetypes = {'gdscript'},
root_dir = vim.fs.dirname(vim.fs.find({'project.godot', '.git'}, {
upward = true,
path = vim.fs.dirname(vim.api.nvim_buf_get_name(0))
})[1]),
on_attach = function(client, bufnr)
vim.api.nvim_command('echo serverstart("' .. pipe .. '")')
end
})
@echo off
wsl wslpath "%1" > tmpfile
set /p filepath= < tmpfile
del tmpfile
wsl nvim --server "/tmp/godot.pipe" --remote-send "<esc>:n %filepath%<CR>:call cursor(%2,%3)<CR>"
@Kuroashi1995
Copy link

Hello everyone, I'm a bit new to nvim. My current question is where do I create or find the nvim.cmd file?

@ACiDiC74
Copy link

ACiDiC74 commented Jan 29, 2025

I was able to get this working, kind of. All the functionality seems to be there, but when trying to get suggestions (using nvim-cmp) it takes 10-15 seconds to get the LSP suggestions, and it seems hit or miss whether the suggestions contain documentation.

This is on Windows 10/wsl2. It is a 10 year old computer with only 8 GBs of RAM, which may be part of the problem, but everything else runs fine on it (not modern games obviously).

For comparison, the same computer booting directly into linux with basically the same configs for neovim (only differences are stuff I needed to add to get the LSP working in wsl) has basically instantaneous suggestions with the documentation always in tact.

I am guessing it is a speed issue with connection between Neovim on WSL2 and Godot on Windows, but I assume others are using wsl fine since I don't see anyone else complaining about speed issues with the methods outlined on this page.

Does anyone have any suggestions to make this work better?

thank you

@TimCreasman
Copy link

@ACiDiC74 You're probably aware, but for whoever else ends here with the same issue like me:
A flag was added that decreases the latency to almost nonexistent called "experimentalFastPathConversion".
My nvim lsp setup looks like this now:

 require("lspconfig").gdscript.setup({
    cmd = { "godot-wsl-lsp", "--useMirroredNetworking", "--experimentalFastPathConversion" },
  })

For those curious, without the flag, the lsp calls wslpath through execFile which will spawn a child_process (either bash or cmd.exe session) and execute the file (the wslpath bin file in this case). This is typically very fast but in some specific environments (some combination of Windows + Node version?) it can be notoriously slow. It's not really clear from that issue what the root cause is unfortunately, but it can exist. The new flag circumvents the call to wslpath altogether and does its own path parsing. Thank you @lucasecdb!!

@ACiDiC74
Copy link

@TimCreasman thank you for the information. I was not aware of this flag. I had ended up getting a new computer (for unrelated reasons) and was still having trouble with this so I gave up and installed a windows version of Neovim. When I have some time I will revisit this and see if I can get it working in wsl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment