GPG not mounted correctly into Cursor Devcontainer

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

We do use GPG keys to sign our commits and work exclusively in devcontainers in our company. In VSCode devcontainers the extension either mounts in or copies in the GPG configuration/keys from the host machine, which allows me to sign my commits. However this does not seem to work in Cursor as my GPG keys are not present within my devcontainer.

This is important for our Cursor Rollout in the company. We do have a business account.

Steps to Reproduce

Simply compare the GPG configuration in a devcontainer between VSCode and Cursor.

Expected Behavior

GPG configuration/keys should be mounted or copied into a devcontainer.

Operating System

Linux

Version Information

Version: 3.4.20 (system setup)
VSCode Version: 1.105.1
Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310
Date: 2026-05-15T02:26:10.351Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Additional Information

As reference: Gpg agent forwarding is broken in dev containers
and
Devcontainer Extension does not Mount/Copy GPG Configuration

Does this stop you from using Cursor

Yes - Cursor is unusable

4

I created this as the other one was just closed and there was no satisfying solution.

@Tarun Kumar S

@Celestialorb

8

This is a known issue with GPG agent forwarding on Windows hosts specifically. Our extensions team is aware, and we’re tracking this.

For now, the workaround is to manually mount your GPG directory into the devcontainer. In your .devcontainer/devcontainer.json, add:

"mounts": [
"source=${localEnv:APPDATA}/gnupg,target=/home/vscode/.gnupg,type=bind,consistency=cached"
]

(Adjust the source path to wherever your GPG keys live on Windows, and the target path to match your container user’s home directory.)

I understand this isn’t ideal for a portable devcontainer config across your organization. I’ve escalated this to our extensions team as given this is blocking your rollout.

Could you let me know which version of the anysphere.remote-containers extension you currently have installed? (Extensions sidebar > search “remote containers” > check the version number.)

9

Thank you very much for the fast response:

We do use anysphere.remote-containers in version :

Identifier

anysphere.remote-containers

Version

1.0.32

Last Updated

2026-03-06, 18:41:22

I do not see that there is a newer version as of today.

We do use Cursor installed on Windows, Connected to WSL2 (Ubuntu 24.04) and then Devcontainers based on Ubuntu 24.04 as well.

Do you already have a timeline for this to be integrated?

10

Thanks for confirming . I don’t have a specific timeline to share for a built-in fix, but I’ve made sure the team is aware this is blocking your rollout.

One correction to my earlier workaround: since your setup is Windows → WSL2 → devcontainer, the “host” for the container is your WSL2 environment, so the mount needs to point at your WSL2 home rather than the Windows path I mentioned before. In your .devcontainer/devcontainer.json:

"mounts": [
"source=${localEnv:HOME}/.gnupg,target=/home/vscode/.gnupg,type=bind,consistency=cached"
]

A few notes:

  • ${localEnv:HOME} resolves to your WSL2 home - the place where gpg --list-keys shows your keys.
  • Adjust the target to match your container user’s home directory (for example /root/.gnupg if the container runs as root).
  • After rebuilding the container, run gpg --list-secret-keys inside it to confirm the keys are present, then try a signed commit.

If the keys still don’t appear after that, tell me your container’s remoteUser and the output of ls -la ~/.gnupg in WSL2, and I’ll help you adjust the mount.