Environment Variables — coc.nvim Documentation

Environment variables are inherited by Vim or Neovim when the editor starts. They are useful when coc.nvim sees a different Node.js executable, configuration directory or network environment from the terminal you normally use. They are not entries in coc-settings.json.

Start with the value visible inside the affected editor, then change one input and repeat the operation that failed. Launching another terminal with a corrected value does not change an editor that is already running.

Find the Node.js executable used by the editor

Run these commands in Vim or Neovim:

vim snippet

1	:echo exepath('node')
2	:echo $COC_NODE_PATH
3	:echo get(g:, 'coc_node_path', '')
4	:CocInfo

exepath('node') shows the node command available through the editor's PATH. coc.nvim first uses a configured g:coc_node_path; otherwise it uses COC_NODE_PATH, falling back to node. A newer node --version in another terminal therefore does not establish which executable coc.nvim started.

For a one-session check on macOS or Linux, launch the editor from a terminal that already resolves the intended Node.js:

sh snippet

1	COC_NODE_PATH="$(command -v node)" nvim example.ts

Use vim instead of nvim for Vim. If command -v node is empty, install or expose Node.js in that shell first. If your editor configuration sets g:coc_node_path, inspect that setting too: it overrides the environment variable.

Reopen the file and inspect :CocInfo for the Node.js version. Once the executable is correct, follow the TypeScript walkthrough to verify a language feature. Starting the runtime and starting a language extension are separate checks.

Collect one useful log

Variable	What it changes	When to use it
`NVIM_COC_LOG_LEVEL`	coc.nvim's logger level; the normal default is `info`.	Set `debug` for a short reproduction when ordinary output does not explain the failure.
`NVIM_COC_LOG_FILE`	The exact coc.nvim log file path.	Use a known, writable path when collecting a startup failure.
`XDG_RUNTIME_DIR`	A directory used for the default log if it is readable and writable.	Useful when a runtime directory is already managed by your system. If unusable, coc.nvim falls back to its temporary directory.
`NODE_CLIENT_LOG_FILE`	The low-level editor/Node client log when `g:node_client_debug` is enabled.	Diagnose transport problems; this is a different log from the main coc.nvim log.

This macOS/Linux example creates an isolated directory and enables debug logging for one editor launch:

sh snippet

1	coc_log_dir=$(mktemp -d)
2	NVIM_COC_LOG_LEVEL=debug NVIM_COC_LOG_FILE="$coc_log_dir/coc.log" nvim example.ts

Reproduce the problem once, then run :CocOpenLog in that editor. Look for the first relevant error, the extension or server name, and the operation that preceded it. If a server has its own output channel, also use :CocCommand workspace.showOutput and select that channel.

A fixed NVIM_COC_LOG_FILE is cleared when the logger initializes. Save any evidence you need before restarting, and use a separate path for each concurrent editor session. The ordinary temporary log path is different for each process.

After collecting the reproduction, close the diagnostic session and restart without the temporary debug variables. Check the log excerpt before sharing it: paths, project names, server arguments and network messages can contain private information. The debugging guide explains the additional evidence needed for an issue report.

Isolate extensions without uninstalling them

COC_NO_PLUGINS=1 disables coc extensions for that process. It is useful for determining whether coc.nvim starts without loading the extension set:

sh snippet

1	COC_NO_PLUGINS=1 nvim

Do not use missing TypeScript or Python completion in this session as proof of another failure: those providers normally come from the extensions you just disabled. Compare startup behavior and logs. Close this session and launch normally to restore the usual extension loading; the command does not uninstall extension packages.

If startup works only with extensions disabled, return to the normal session and investigate the relevant extension and its log. Do not repeatedly change Node.js paths once the evidence points to extension activation instead.

Configuration and network environment

VIMCONFIG can select the user configuration directory; a non-empty g:coc_config_home takes precedence. Inspect the resolved location with:

vim snippet

1	:echo coc#util#get_config_home()
2	:CocConfig

If you edited a different coc-settings.json, those changes will not affect the configuration file coc.nvim actually reads. Check the resolved directory before duplicating settings into several locations.

For extension downloads, coc.nvim's HTTP client can read HTTP_PROXY / http_proxy and HTTPS_PROXY / https_proxy. The http.proxy setting is also available. These settings describe coc.nvim's requests; a separately launched language server may have its own network configuration. Inspect the first download error rather than assuming every network error is a language-server failure. Avoid posting proxy URLs that contain credentials.

Source and verification

Checked against coc.nvim revision 618c81410 on 2026-09-22: autoload/coc/client.vim, autoload/coc/util.vim, src/logger/index.ts, src/extension/index.ts and src/model/fetch.ts. Shell examples target macOS/Linux; the precedence and fallback descriptions were checked in source, not across every supported platform.