Dev Mode failing on openvscode-server

A bug in Hugging Face's Dev Mode image layer prevents OpenVSCode Server from building, failing at the ms-python.debugpy extension installation step. The issue occurs before any application or GPU workload starts, and the recommended action is to report it to Hugging Face with minimal reproduction logs.

Oh… It looks like you may have run into an unknown Hugging Face-side bug here. I couldn’t find a practical workaround at the moment, so I think the best next step is to report it to Hugging Face. Details: just in case, @hysts https://discuss.huggingface.co/u/hysts The failure appears to happen in the Dev Mode image layer generated by Hugging Face , before your application or its GPU workload starts. The relevant generated step is trying to install both: ms-python.python ms-python.debugpy ms-python.python installs successfully, but resolving ms-python.debugpy fails, and that one failure terminates the entire Dev Mode image build. That distinction matters because the Spaces Dev Mode documentation https://huggingface.co/docs/hub/spaces-dev-mode says that the Dev Mode image starts all of the following together: I could not find a documented option to: So, unfortunately, even though you only need SSH, the failed editor-extension setup appears to prevent the SSH-enabled Dev Mode container from being created at all. I would not treat the T4 as the main suspect yet. The build is failing while preparing OpenVSCode extensions, before CUDA initialization or your application’s performance-sensitive code should be running. More importantly, the remaining useful questions concern information that only Hugging Face can inspect internally: the exact OpenVSCode build they injected, the registry endpoint and response seen by the builder, any proxy/cache layer, and whether this is isolated to a particular builder pool or environment. I would stop looking for increasingly indirect workarounds for now and turn this into a small, actionable Dev Mode reproduction for Hugging Face. The default path I would use is: You do not need to test every hardware type or every possible configuration. Even one clean comparison would make the report substantially more useful. A minimal result matrix would be: | Result | What it would suggest | |---|---| | Normal build succeeds; Dev Mode fails | The failure is probably in the additional Dev Mode layer rather than the application build itself | Official minimal example fails at the same ms-python.debugpy step | Strong evidence for an HF-side Dev Mode builder, registry-integration, or account/builder-path issue | | Official minimal example succeeds; the original Space fails | Compare the Space SDK, base image, Docker layout, architecture, and generated OpenVSCode version | | CPU minimal example also fails | The T4 is probably irrelevant | | CPU succeeds but T4 fails | Useful evidence for a hardware-specific builder path or builder-pool difference | | A later retry succeeds without repository changes | A transient registry, cache, proxy, or builder issue becomes more plausible | The most useful bundle would be: In particular, look slightly earlier in the build log for something resembling: openvscode-server-vX.Y.Z-linux-x64.tar.gz The exact version and target platform may be much more useful to HF than the final Extension not found line alone. You can retrieve build logs from the CLI with the officially documented command: hf spaces logs <namespace /<space --build Before posting logs publicly, remove access tokens, temporary signed URLs, private repository details, or other secrets if any appear. Why this looks like a generated Dev Mode-layer failureI do not see a supported way to recover SSH from this failed Dev Mode build while simply ignoring the VS Code server. The strongest next step is therefore: If the official minimal Space fails at the same extension step, provide HF with both Space IDs and the matching logs. If the minimal Space succeeds, compare the generated OpenVSCode version, platform target, and Dev Mode prerequisites against the original Space. Either result is more actionable than trying to guess externally whether the hidden cause is OpenVSCode version selection, Open VSX visibility, an HF proxy/cache, or a particular builder pool.