artrz
Stash UI disappears in Remote - Containers since version 6.8.0
The Git Stash extension no longer shows the Stashes view when using VS Code Remote - Containers. The extension activates successfully, but the UI tab is missing. This only happens in Remote - Containers; in local or SSH remote sessions, the view appears as expected.
I tested with multiple versions and can see this behaviour since version 6.8.0 (VSCode Version: 1.104.1)
How to Reproduce It is only applicable to containerised development workflow
- Connect to a running container (assuming you use Docker for development)
- Go to Source Control Tab
- Stash tab is missing there
Expected behavior In case of older versions or in case of newer version but when containers are not involved, stash tab is present in the UI.
Screenshots
Screenshot for the situation when version 6.9.0 or 6.8.0 is installed and vscode is connected to vscode remote server inside a container
In case version 6.7.0 is installed (or vscode running locally or attached to a remote vscode server but not within a container):
System VSCode Version: 1.104.1, Dev Containers 0.427.0, macOS 15.6.1 (24G90),
Additional context In case when this UI bag is present it was also checked:
- Stashes exist: ran git stash list inside the container terminal → stashes are present.
- Verified repo is accessible: .git is mounted inside the container and Git is installed.
- Confirmed extension is installed & enabled in container
- Git Stash (arturock.gitstash) shows up in the Remote – Dev Container extensions list and is enabled.
- Verified extension is running: In Developer: Show Running Extensions, Git Stash was listed as active.
- Extension remote host log shows: [info] ExtensionService#_doActivateExtension arturock.gitstash, startup: false, activationEvent: 'onStartupFinished'
- Git extension (vscode.git) is active and working (Source Control view present).
- Works fine in local VS Code.
- Works fine in VS Code Remote – SSH.
- Only missing in Remote – Containers.
- No errors were present in the output tab when Git Stash is selected (output is empty)
And also just wanted to say thank you for your work! This is a must-have vscode extension imo, makes it really easy to manage repositories, especially when there are frequent merges/local changes/conflicts
Hi @voeykovroman. I don't currently use Dev Containers so I have zero experience but I made some tests and for some reason the extension correctly loads on my end having a very similar setup. Same OS, same vscode version (when issue was reported) and same DevContainers ext version.
In my case it behaved strangely at first. it worked after I set up the container, downgraded to v6.7.0 and when upgrading it stopped working. I uninstalled the extension, (I don't remember if I) restarted the editor, cleared broken workspaces cache and everything looking suspicious using the Workspace Storage Cleanup extension, closed, reopened, and finally I installed from the marketplace. Seems to work correctly now.
My remote host log also shows ExtensionService#_doActivateExtension arturock.gitstash, startup: false, activationEvent: 'onStartupFinished'. Looks like it only logs the extensions to run but not when they're actually started.
The following is my (barebones) config in case is not complex enough to replicate the issue or maybe you can spot something.
Latest extension versions start logging git commands since the startup so it may worth to take a look at the Git Stash log output to see if there's an error logged there.
Thanks for the kind words, I really appreciate it!!
Thanks for the analysis! In my case it's a slightly different setup. There is a running container on the machine with my project (which is a standard git tracked repo) mounted inside /workspace directory in the container. So there is no .devcontainer/devcontainer.json as I am not building one with this feature but just attaching VS Code to a pre-existing container using the “Attach to Running Container” feature. Then in the output of Git Stash (using the latest version) I can see:
2025-10-02 13:01:54 > git rev-parse --show-toplevel
fatal: detected dubious ownership in repository at '/workspace'
To add an exception for this directory, call:
git config --global --add safe.directory /workspace
however, adding /workspace to safe.directory doesn't prevent this warning from happening. And when I just run git rev-parse --show-toplevel in terminal running inside a container I just got /workspace. Also, when I check "Output" tab when Git is selected (instead of Git Stash) I got no errors when the same rev-parse command is running:
2025-10-02 15:45:46.593 [info] [main] Log level: Info
2025-10-02 15:45:46.593 [info] [main] Validating found git in: "git"
2025-10-02 15:45:46.593 [info] [main] Using git "2.43.0" from "git"
2025-10-02 15:45:46.593 [info] [Model][doInitialScan] Initial repository scan started
2025-10-02 15:45:46.593 [info] > git rev-parse --show-toplevel [1ms]
2025-10-02 15:45:46.593 [info] > git rev-parse --git-dir --git-common-dir --show-superproject-working-tree [2ms]
2025-10-02 15:45:46.593 [info] [Model][openRepository] Opened repository (path): /workspace
2025-10-02 15:45:46.593 [info] [Model][openRepository] Opened repository (real path): /workspace
2025-10-02 15:45:46.593 [info] [Model][openRepository] Opened repository (kind): repository
So it probably looks like the extension uses different git installation/instance/client (not sure what is the correct terminology here) rather than the git client used by VSCode itself.
Btw, worskpace Storage cleanup didn't help in my case unfortunately, it's still the same behaviour: it works with older versions and doesn't work with the more recent one.
Sorry for the off-top, but while debugging I ran into a problem similar to what is described in issue 130 with the preview of the diff not working. But again, in my case it only happened inside the container, and as far as I can see was introduced with the update from 6.6.1 to 6.6.2. Most likely unrelated to the main issue here but shared just in case.