I am having a real problem with VSC workspace "trust"

I can’t seem to get it to allow xonsh to cwd to the workspace. I’ve added, even the \ version of the path, and nothing seems to affect. It just keeps saying that “Cannot launch a terminal process in an untrusted workspace with cwd \home\me\project and userHome \home\me, even though I have added it as a trusted source. both / and \ versions, since one of the answer on the web said to try this. However, the \ version didn’t show up until I added it, it was always the / version before I added the \ version.
There has got to be a way around this. I tried turning off trust altogether, but it still happens.

Any help would be much appreciated.

Hi, I’m the Toradex AI Assistant.

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


I understand you’re experiencing a VS Code workspace trust issue when trying to use xonsh terminal in your Torizon project. Based on the available community discussions, this appears to be related to VS Code’s workspace trust mechanism rather than a Torizon-specific issue.

Common Solutions for Workspace Trust Issues

1. Verify Workspace Configuration

The most common cause is having the wrong workspace folder selected. As mentioned in a similar case(1), ensure that:

  • Your VS Code workspace is opened at the correct project root (e.g., /home/me/project/ not /home/me/)
  • Use File → Open Folder to select the specific project directory
  • Save the workspace using File → Save Workspace As within your project folder(1)

2. Check Torizon Project Settings

Verify your .vscode/settings.json contains the correct workspace configuration. The workspace path should match your actual project location(1).

3. Terminal and Path Issues

Since you’re using xonsh, the path format differences between / and \ suggest there might be a shell or path resolution conflict. The Torizon IDE Extension expects standard Unix-style paths for containerized development.

Recommended Steps

  1. Restart VS Code with the correct project folder as your workspace root
  2. Clear any cached trust settings by closing VS Code completely
  3. Ensure your project structure matches the expected Torizon workspace layout
  4. Try using the default terminal first to verify the workspace trust is resolved, then switch back to xonsh

If these steps don’t resolve the issue, the problem may be related to xonsh’s interaction with VS Code’s workspace trust mechanism rather than the Torizon development environment itself.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

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

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

@eric.tx @ToradexAI
Nothing has worked. It just keeps saying what I reported before. I have tried opening and reopening VSC over and over after every attempt, with the same issue.
What does Number 3) above mean exactly? I have my code and a working Makefile in my folder. I am trying to run a C++ compile and program a Verdin board, that up until Monday was working. And now, I just keep getting the XONSH which fails with trust issues. WHY?

C++ Torizon Project Trust Issues

Based on the community discussions, this appears to be a permissions and workspace configuration issue that affects C++ projects specifically. Let me address your specific situation:

What Point 3 Means - Expected Project Structure

For a C++ Torizon project to work properly, your workspace should contain(1):

  • .vscode/ folder with configuration files
  • docker-compose.yml file
  • Your source code and Makefile
  • Proper container configuration files

C++ Specific Issues

The community has reported similar C++ compilation failures(2). The error you’re seeing suggests a permissions issue where the container cannot write to your project directory(2).

Immediate Solutions to Try

1. Check Directory Permissions

Ensure your project directory has correct write permissions(2):

chmod -R 755 /home/me/project

(2)

2. Verify Docker Volume Mounting

The issue often stems from Docker volume mounting problems where the container cannot access your project files properly(2).

3. Try Without xonsh

Since this started Monday and was working before, try using the default bash terminal instead of xonsh to isolate whether the issue is shell-specific or workspace-specific.

C++ Template Specific Information

The C++ Console Template uses specific compilation tasks(2):

  • build-makedir-${architecture} - creates destination directory
  • build-debug-${architecture} - compiles the code
  • Uses SDK containers for cross-compilation
  • Copies compiled code using scp in the deploy-torizon-${architecture} task

If Nothing Works

Since this was working until Monday, something in your environment changed. Try:

  1. Create a fresh C++ project from the Torizon template to test if the issue is project-specific
  2. Check if VS Code or the Torizon Extension updated recently
  3. Verify your Docker installation is still working properly

The fact that it suddenly stopped working suggests an environment change rather than a project configuration issue.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

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

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

@ToradexAI @eric.tx
Well, no, as I mentioned previously, VSC updated and started using XONSH build process, which I was not using before.
Steve

VS Code Extension Update and xonsh Integration

Based on the community discussions, you’re correct that recent VS Code Extension updates have introduced xonsh as part of the build process. This is a known change that has affected several users.

Understanding the xonsh Integration

The Torizon IDE Extension now uses xonsh scripts for various tasks. From the community discussions, we can see that xonsh is used for tasks like:

  • check-deps task for dependency validation(1)
  • Project configuration and validation scripts(1)
  • Build process management(1)

Workspace Trust and xonsh Issues

The community has identified that the .vscode folder location is critical for proper operation(2). As explained in the community:

“The location of the .vscode folder is something defined by VS Code itself and is not something specific to the Torizon IDE extension… VS Code stores workspace settings at the root of the project in a .vscode folder”(2)

Resolving the Trust Issue

Since this started after the VS Code update, the issue is likely related to how the new xonsh integration interacts with VS Code’s workspace trust mechanism. Here are the specific steps:

1. Ensure Proper Project Structure

Your project needs the standard Torizon structure with .vscode and .conf folders at the project root(2). Moving these folders to non-standard locations can cause the extension to fail(2).

2. Workspace Configuration

The extension expects specific workspace settings. In multi-container projects, settings are defined in the .code-workspace file rather than individual .vscode/settings.json files(3).

3. xonsh Script Dependencies

The extension now runs validation scripts that check your environment(1). These scripts need proper permissions and workspace trust to execute.

Immediate Solution

Since you had a working setup before the update, try:

  1. Verify your .vscode folder is at the project root(2)
  2. Check that your workspace is properly trusted in VS Code settings
  3. Ensure the xonsh validation scripts can execute - this may require adjusting your system’s execution policies

The community discussions show that users have resolved similar issues by ensuring the proper project structure and workspace configuration are maintained(2).

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

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

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

Hey Steve,

i had the same issue and found this Thread about VS-Code

https://github.com/microsoft/vscode/issues/277808#issuecomment-3540974552

so i added

“options”: {

    "cwd": ""

  },

to the tasks that had the issues in taks.json and it worked for me.

Maybe you should giv it a try to.

This did work, but I had to do it in places I wasn’t expecting, like anything that had to do with “xonsh”. But adding it seems to have done the trick. However, I feel that this is just a bandaid which I HATE. But it gets me going. So Thank you!

Steve