Extensions Fail to Install in Dev Containers (confirmed linux-arm64, may affect other architectures)

[acamp (Alex Campino)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

Extensions cannot be installed inside a devcontainer running on linux-arm64. Both the marketplace UI install and CLI --install-extension fail with the same error. The root cause is a missing node-ovsx-sign module in the cursor-server bundle, which causes extension signature verification (sigzip download) to fail, which cascades into a full rollback of all extensions in the install batch.

Affected Extensions

• ms-python.python (2025.6.1)
• ms-python.debugpy (2025.18.0)
• ms-python.autopep8 (2025.2.0)
• anysphere.cursorpyright (1.0.10)

Not affected: dbaeumer.vscode-eslint (3.0.20) installs successfully.

Steps to Reproduce

Steps to Reproduce

1. Create a devcontainer with this devcontainer.json:

   {
     "name": "Python 3",
     "image": "mcr.microsoft.com/devcontainers/python:2-3.14-trixie",
     "customizations": {
       "vscode": {
         "extensions": [
           "ms-python.python",
           "ms-python.debugpy"
         ]
       }
     }
   }
   

2. Open the devcontainer in Cursor on an ARM64 host (e.g. Apple Silicon Mac).

3. Observe that the Python extensions fail to install.

4. Attempting to install manually via the Extensions sidebar also fails.

5. Attempting via CLI (cursor --install-extension ms-python.python) also fails.

Expected Behavior

Expected Behavior

Extensions specified in devcontainer.json customizations.vscode.extensions should install successfully. If signature verification is unavailable, it should either:

1. Fall back gracefully (install without verification), or
2. Ship the node-ovsx-sign module for all platforms, or
3. Pre-cache all required sigzips in the devcontainer image

Operating System

Linux

Version Information

Environment

Detail	Value
Cursor version	2.5.20 (commit 511523af765daeb1fa69500ab0df5b6524424610)
VS Code version	1.105.1
Platform	linux-arm64 (aarch64)
Container OS	Debian 13 (trixie)
Container image	mcr.microsoft.com/devcontainers/python:2-3.14-trixie
Host kernel	6.10.14-linuxkit

Additional Information

Root Cause Analysis

Three issues were identified in the logs at ~/.cursor-server/data/logs/*/remoteagent.log:

Issue 1: Missing node-ovsx-sign module

[error] Could not load node-ovsx-sign module Cannot find package 'node-ovsx-sign'
  imported from /vscode/cursor-server/bin/linux-arm64/.../out/server-main.js

The node-ovsx-sign package is not bundled with the cursor-server for linux-arm64. This module is responsible for verifying extension signatures. Note: node-ovsx-sign is completely absent from node_modules/ (not a broken native binary — it was never included). This may affect other architectures as well if the module is similarly excluded from those builds.

Issue 2: Sigzip download returns invalid data

With the signing module missing, the server falls back to downloading .sigzip files for signature verification. For several extensions, this download returns data that is not a valid zip file:

[warning] Failed downloading sigzip. End of central directory record signature not found.
  Either not a zip file, or file is truncated.. Retry again... ms-python.python

This retries twice and then fails. Notably:

• Some extensions (ruff, autopep8, debugpy) have valid pre-cached .sigzip files in /vscode/cursor-server/extensionsCache/
• ms-python.python and anysphere.cursorpyright do NOT have pre-cached sigzips, so they must be downloaded at runtime, and that download fails

Issue 3: Cascading rollback destroys successfully installed extensions

When sigzip verification fails for ms-python.python or anysphere.cursorpyright, the entire install batch is rolled back — including extensions that were already successfully extracted and renamed:

[info] Extracted extension to .../ms-python.debugpy-2025.18.0-linux-arm64: ms-python.debugpy
[info] Renamed to /home/vscode/.cursor-server/extensions/ms-python.debugpy-2025.18.0-linux-arm64
...
[error] Error while installing the extension ms-python.python End of central directory record...
...
[info] Rollback: Uninstalled extension ms-python.debugpy     <-- debugpy was fine but gets rolled back
[info] Rollback: Uninstalled extension ms-python.autopep8    <-- autopep8 was fine but gets rolled back

ms-python.python has dependency on ms-python.debugpy and anysphere.cursorpyright, so when Python fails, all three are rolled back. This means zero Python extensions survive.

Additional Observations

Pre-cached extensions cache is incomplete

The devcontainer image pre-caches some extensions at /vscode/cursor-server/extensionsCache/, but the sigzip coverage is inconsistent:

Extension	.vsix cached	.sigzip cached
charliermarsh.ruff	Yes	Yes
ms-python.autopep8	Yes	Yes
ms-python.debugpy	Yes	Yes
ms-python.python	Yes	No
anysphere.cursorpyright	Yes	No

RequestStore#acceptReply warnings

The logs also show 84+ sequential warnings:

[warning] RequestStore#acceptReply was called without receiving a matching request 1
...
[warning] RequestStore#acceptReply was called without receiving a matching request 84

This suggests a broader connection/protocol issue between the Cursor client and server in the devcontainer.

Regression Confirmation

This is a regression in Cursor 2.5.x.

Downgrading to Cursor 2.4 resolves the issue — all extensions (ms-python.python, ms-python.debugpy, ms-python.autopep8, anysphere.cursorpyright) install successfully on the same devcontainer with no changes to devcontainer.json.

This means the sigzip verification behavior that breaks extension installation was introduced in the 2.5 release line. Cursor 2.4 either doesn’t perform sigzip verification or handles the missing node-ovsx-sign module gracefully.

Workaround

Downgrade to Cursor 2.4 and disable auto-update (Cursor Settings > Application > Update > Manual).

Architecture Notes

This bug was confirmed on linux-arm64 (Apple Silicon Mac host). It may also affect linux-x64 — the node-ovsx-sign module is completely absent from the server’s node_modules/ directory (not a broken native binary, just never bundled), and the sigzip download failures appear to be server-side/network-level rather than architecture-dependent. The Cursor team should verify whether x64 devcontainers are similarly affected.

Log File Location

~/.cursor-server/data/logs/20260220T233015/remoteagent.log

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[dannyp]

Confirming that I am seeing the same issue with Cursor 2.5.20 and wanted to shout out that this is a wonderful bug report @acamp tyty

[Colin]

I agree with @dannyp — you should teach lessons @acamp!

Signature verification is new in Cursor (and I thought, still disabled behind a feature flag), and we probably missed something here. I’ll send it directly to the team.

[acamp (Alex Campino)]

Thank you guys. As much as I’d like to take the accolades here, it was all Cursor doing the digging. I just pointed it to the right place and let it cook

Thanks for looking into this!

[victorsmoliveira (Victor De Simone Oliveira)]

Confirmed the same thing happening in Cursor 2.5. Downgrading to 2.4 solved the issue. This must be addressed!

[victorsmoliveira (Victor De Simone Oliveira)]

any news? @Colin

[Colin]

Hey there! I believe a fix was merged into 2.5.21 (the latest version is 2.5.26 right now). Could you please give it a try? It’s a bit tough as we haven’t been able to reproduce it internally, but we’re pretty confident that we fixed it.

[victorsmoliveira (Victor De Simone Oliveira)]

Looks like it’s fixed!! Thank you very much @Colin

[acamp (Alex Campino)]

Can confirm it is working! Thank you all!