I understand your concern about working within the Torizon IDE Extension’s build process. Let me explain how the debugging workflow works and provide some practical solutions for your network connectivity issue.
How the Torizon IDE Extension Build Process Works
The Torizon IDE Extension uses different containers for different purposes (1):
SDK Container
The SDK container runs on your host machine and cross-compiles your code (1). It uses bind-mounting to share the workspace directory:
{
"label": "build-debug-arm64",
"detail": "Build a debug version of the application for arm64 using\nthe toolchain from the SDK container.",
"command": "DOCKER_HOST=",
"type": "shell",
"args": [
"docker",
"run",
"--rm",
"-it",
"-v",
"${workspaceFolder}:${config:torizon_app_root}",
"cross-toolchain-arm64-__container__",
"cmake",
"--build",
"build-arm64"
]
}
(1)
Debug Container
The debug container is deployed to your target device via SSH (1). Build files are copied through rsync, not pulled from a registry:
{
"label": "deploy-torizon-arm64",
"detail": "",
"hide": true,
"command": "rsync",
"type": "process",
"args": [
"-P"
]
}
(1)
Solutions for Your Network Configuration
Option 1: Modify the Local Registry Configuration
The Torizon IDE Extension uses a local registry (localhost:5002) (2). You can modify the tasks to use the save/load approach instead of registry pulls.
Option 2: Use Release Container Tasks
The run-container-torizon-release-<arch> task performs these steps (2):
- Build a container image based on
Dockerfile
- Push the container image to the local container registry (localhost:5002)
- Pull the container image to your SoM
- Run the container using
docker-compose.yml configuration
Option 3: Custom Task Modification
You can create custom tasks in your .vscode/tasks.json that:
- Build the container locally
- Save it as a tar file
- Transfer via SCP (which works in your network)
- Load and run on the device
Workspace File Handling
The extension handles files differently for each container type (1):
- SDK container: Mounts the workspace directory directly
- Debug container: Copies only the build directory via SSH
- Release container: Uses multi-stage builds with
COPY commands
Since you can establish SSH connections to your device, the debug workflow should work fine - it doesn’t rely on the device pulling from your laptop registry, but rather uses direct file transfer via SSH.
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.
VALIDATING ENVIRONMENT
Environment is valid!
localhost:5002/hw1-debug:arm64 Built 0.0s