Torizon IDE extension: torizon.overwriteHostIp ignored in VS Code multi-root workspace on WSL

Vivien · August 4, 2026, 7:04am

Hello,

I am experiencing an issue with the Torizon IDE extension where it appears to keep using an outdated host IP address when populating host_ip in settings.

Environment

Host OS: Windows with WSL2
VS Code Torizon IDE extension: 3.6.0
Project type: Multi-root VS Code workspace
Target: Verdin iMX8M Plus running Torizon OS

Problem

My host IP address has changed. However, the Torizon IDE extension still appears to use the old IP address.

The board itself is detected and connected correctly. I can SSH into it using the option in the Torizon IDE extension tab.

It does not appear to be a project configuration problem as my colleague does not experience this issue when working on the same project.

What I tried

I configured the setting torizon.overwriteHostIp through the VS Code Settings UI:

I tried setting it at the following relevant scopes:

WSL remote settings
Multi-root workspace settings in the .code-workspace file
Individual folder workspace settings

I also tried:

Restarting VS Code and my host computer
Disconnecting and reconnecting the target board by selecting the board again as the default Torizon device

Despite this, the extension continues to use the old host IP.

Questions

Is torizon.overwriteHostIp supported for multi-root workspaces?
At which configuration scope is the Torizon extension expected to read this setting when running under WSL?
Is the setting evaluated every time a task is run, or only when the project/device configuration is initially generated?
Is there another cached or generated host-IP value that must be cleared?
Am I missing something?

Thank you in advance for any insights you may have!

Best regards,

Vivien

ToradexAI · August 4, 2026, 7:04am

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Addressing `torizon.overwriteHostIp` in Multi-Root Workspaces

Based on the documentation and community discussions, here’s what I found regarding your issue:

Understanding `torizon.overwriteHostIp`

According to the official documentation, torizon.overwriteHostIp is designed to override the automatically detected IP address(1). The documentation states: “The IP address set here will overwrite the IP address set automatically into host_ip, from project .vscode/settings.json. Use it as fallback if the automatic IP address set is getting it from the wrong interface for example.”(1)

Known Multi-NIC and WSL Issues

Community reports indicate similar issues in multi-NIC environments and WSL scenarios(2)(3). In one case, a user experienced the extension incorrectly assigning 169.254.201.164 instead of the correct IP(2). Another user working on WSL with multiple network interfaces found that the extension was selecting the wrong interface IP(3).

Answers to Your Questions

Multi-root workspace support: The documentation doesn’t explicitly confirm multi-root workspace support for torizon.overwriteHostIp. The setting appears designed for single-project scenarios.
Configuration scope: For WSL environments, the extension should read from the WSL remote settings, but multi-NIC scenarios are a known limitation(3).
Evaluation timing: The host_ip value is set automatically by the extension when you configure your default device(1).
Cached values: Yes, the host_ip in .vscode/settings.json persists until explicitly changed or the device is reconfigured.
Workaround: Directly editing host_ip in .vscode/settings.json for each project folder in your multi-root workspace is currently the most reliable approach(3).

Additional Note

This is a known limitation of the extension in multi-NIC and complex network environments(3). The development team is aware of these scenarios.

Best regards,
Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

jeremias.tx · August 4, 2026, 6:24pm

Greetings @Vivien,

Just to make sure we have the full context. What is the exact error message you are seeing here?

Also it’s strange that the old IP address is being used here. Just as a sanity check, if you create a new project with our extension. Is the old or new IP address being used?

That might help to narrow whether it’s a project setting on your specific PC that is being cached somewhere or not.

Best Regards,
Jeremias

Vivien · August 6, 2026, 10:02am

Hello @jeremias.tx ,

Thank you for your response.

I do not receive a specific error message when selecting my device as the default device in the Torizon IDE extension. The issue is that the host_ip value is populated incorrectly in all settings.json files and in the project workspace.

When I run the run-containers-release-arm64 task from the multi-root workspace, I eventually get the following error when the board tries to pull the images from my host:

Executing task in folder multi-root-project: DOCKER_HOST=<correct_torizon_ip>:2375 DOCKER_LOGIN=<old_host_ip>:5002 TAG=v0.0.0 GPU=-imx8 DEBUG_SSH_PORT=1 DEBUG_PORT1=1 DEBUG_PORT2=1 DEBUG_PORT3=1 docker compose -p torizon --profile release up

WARN[0000] The “LOCAL_REGISTRY” variable is not set. Defaulting to a blank string.
WARN[0000] The “LOCAL_REGISTRY” variable is not set. Defaulting to a blank string.
WARN[0000] The “LOCAL_REGISTRY” variable is not set. Defaulting to a blank string.
WARN[0000] The “LOCAL_REGISTRY” variable is not set. Defaulting to a blank string.
[+] Running 4/4
✘ app1 Error Get “http://<old_host_ip>:5002/v2/”: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 30.0s
! app2 Interrupted 30.0s
! app3 Interrupted 30.0s
! app4 Interrupted 30.0s
Error response from daemon: Get “http://<old_host_ip>:5002/v2/”: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

This behavior makes sense because the board is trying to pull the containers from my old host IP address, where no registry server is listening.

The work around of @ToradexAI to manually set host_ip and update manually the docker deamon on the board is working. However, this is not very practical because I need to update host_ip in five different places and repeat the procedure every time I switch boards. These values are also overwritten again by the Torizon IDE extension.

I expected the torizon.overwriteHostIp setting to be useful in exactly this situation, but I have not been able to make the extension take it into account.

I also tried creating a new Torizon project, but the host_ip value was still populated incorrectly.

Best regards,
Vivien

ToradexAI · August 6, 2026, 10:03am

Hi Vivien,

Thank you for the detailed clarification. Based on your description, it appears the Torizon IDE extension is not respecting the torizon.overwriteHostIp setting in your multi-root workspace environment on WSL.

Understanding the Issue

The error you're encountering shows that DOCKER_LOGIN is being set to your old host IP (<old_host_ip>:5002), causing the target board to attempt pulling container images from a registry that no longer exists at that address[(1)](https://community.toradex.com/t/torizoncore-example-c-project/27893).

According to the documentation, torizon.overwriteHostIp should override the automatically detected IP address that gets written to host_ip in your project's .vscode/settings.json[(2)](https://developer.toradex.com/torizon/application-development/ide-extension/reference-documentation/workspace-settings). The setting is specifically designed as "a fallback if the automatic IP address set is getting it from the wrong interface"[(2)](https://developer.toradex.com/torizon/application-development/ide-extension/reference-documentation/workspace-settings).

Potential Causes

1. Multi-Root Workspace Limitation

The documentation does not explicitly address multi-root workspace support for torizon.overwriteHostIp. The extension's behavior in multi-root workspaces may differ from single-folder projects, particularly regarding how settings are read and applied.

2. WSL Network Interface Detection

WSL environments with multiple network interfaces are known to cause issues with automatic IP detection[(3)](https://community.toradex.com/t/update-fails-many-times-from-torizon-clouad/27484)[(1)](https://community.toradex.com/t/torizoncore-example-c-project/27893). The extension may be caching or detecting the wrong interface, and in WSL scenarios, the automatic detection mechanism appears to have limitations.

3. Settings Scope Priority

VS Code has a settings hierarchy (User → Remote → Workspace → Folder). In multi-root workspaces, the extension may not be reading torizon.overwriteHostIp from the expected scope, or there may be conflicting values across different scopes.

Diagnostic Steps

To help narrow down the issue:

Check VS Code settings hierarchy: Open the Command Palette (Ctrl+Shift+P) and run "Preferences: Open Settings (JSON)". Search for torizon.overwriteHostIp to see where it's defined and what value is being used.
Verify network interfaces: Run ip addr show in your WSL terminal to identify all active interfaces and their IPs[(3)](https://community.toradex.com/t/update-fails-many-times-from-torizon-clouad/27484). This will help confirm which IP the extension should be using.
Check extension logs: Open the Developer Tools in VS Code (Help → Toggle Developer Tools), go to the Console tab, and look for any messages from the Torizon extension related to IP detection or settings[(4)](https://developer.toradex.com/torizon/application-development/ide-extension/troubleshooting).

Workaround for Multi-Root Workspaces

While not ideal, here's a more streamlined approach than manually editing five different locations:

Set host_ip in each folder's .vscode/settings.json:
```
{
  "host_ip": "<your-new-host-ip>"
}
```
Update the target board's Docker daemon configuration once: On your Verdin iMX8M Plus, edit /etc/docker/daemon.json[(3)](https://community.toradex.com/t/update-fails-many-times-from-torizon-clouad/27484):
```
{
  "insecure-registries": ["<your-new-host-ip>:5002"]
}
```
Then restart Docker:
```
sudo systemctl restart docker
```

Recommendation

This appears to be a limitation or bug in how the extension handles torizon.overwriteHostIp in multi-root workspaces on WSL. Since you've confirmed the issue persists even with new projects, and the setting is not being respected despite being configured at multiple scopes, I recommend reporting this as a bug to the Toradex development team through the Toradex Community or GitHub issues for the extension.

In the meantime, the manual host_ip override in each project's .vscode/settings.json is the most reliable workaround[(1)](https://community.toradex.com/t/torizoncore-example-c-project/27893).