adom-vscode
Public Made by Adomby adom
Let Claude, Codex and Kimi drive VS Code inside your Adom container
extensions --latest ignores target platform: reports phantom updates; should return both platform-scoped and cross-platform results
adom/adom-vscode 1.1.14 (extension + CLI running 1.1.13) · adom/core 4.13.13 · code-server 4.131.0 (official .deb) · Linux x64 container (hd)
Summary
adom-vscode extensions status <id> --latest queries the Open VSX native REST API, which is target-platform agnostic. For platform-specific extensions it therefore reports updateAvailable: true for versions that code-server can never resolve or install on this machine. It should default to a platform-targeted query so it agrees with the real update path — and additionally return the broader cross-platform picture, with an _hint telling the AI how to get more.
What I did
Checked whether a newer Claude Code extension existed:
adom-vscode extensions status anthropic.claude-code --latest
What I expected
A latestVersion that reflects what code-server could actually install on this platform.
What happened
{
"id": "Anthropic.claude-code",
"version": "2.1.229",
"latestVersion": "2.1.231",
"updateAvailable": true,
"path": ".../anthropic.claude-code-2.1.229-linux-x64"
}
So I told the user to update. POST /extensions/update returned the usual "update requested — activates on reload" and then nothing downloaded. No new directory, no change to extensions.json, no .obsolete entry.
That is because code-server was right and --latest was wrong. Querying Open VSX's VS Code-compat gallery — the endpoint code-server actually uses, per lib/vscode/out/server-main.js — gives:
POST https://open-vsx.org/vscode/gallery/extensionquery (pageSize 100, flags 951)
total version rows: 9
linux-x64 rows: ['2.1.229']
distinct versions: 2.1.231, 2.1.229, 2.1.228, 2.1.89
2.1.231 was listed for alpine-x64, darwin-arm64, darwin-x64, linux-arm64 and win32-x64 — but not linux-x64. code-server correctly concluded there was no newer build for its platform and did nothing.
Meanwhile the native API that --latest uses reports a bare 2.1.231 with no platform qualification:
GET https://open-vsx.org/api/Anthropic/claude-code → 2.1.231
GET https://open-vsx.org/api/Anthropic/claude-code/linux-x64/2.1.231 → real linux-x64 VSIX (94 MB)
The linux-x64 artifact does exist and installs fine by hand; it is the compat gallery listing that lags. Either way, --latest as written cannot tell the difference between "a newer build exists for you" and "a newer build exists for somebody else's platform".
Why this matters
This sent me on a ~20-minute detour. I concluded from the silent no-op that the container had no marketplace configured at all, and started auditing product.json, the systemd unit and --disable-update-check for a misconfiguration that did not exist. A platform-aware latestVersion would have said "you are current" and none of that happens.
It affects all three AI assistants (anthropic.claude-code, openai.chatgpt, moonshot-ai.kimi-code) since they all ship platform-specific builds — exactly the extensions users most often ask about.
Requested change
1. Default to a platform-targeted query. latestVersion / updateAvailable should reflect the installed extension's target platform, so they agree with what extensions update can actually deliver. Derive the platform from the installed extension's targetPlatform (or the directory suffix), falling back to the host arch.
2. Do not throw the cross-platform data away. Return both payloads. Knowing that 2.1.231 shipped for five other platforms while linux-x64 is stuck on 2.1.229 is exactly what diagnosed this — it is the signal that distinguishes "you are current" from "your platform is lagging the release". Something like:
{
"id": "Anthropic.claude-code",
"version": "2.1.229",
"targetPlatform": "linux-x64",
"latestVersion": "2.1.229",
"updateAvailable": false,
"allPlatforms": {
"latestVersion": "2.1.231",
"platforms": {
"linux-x64": "2.1.229",
"linux-arm64": "2.1.231",
"darwin-arm64": "2.1.231",
"win32-x64": "2.1.231"
}
},
"_hint": "latestVersion is scoped to targetPlatform linux-x64, matching what code-server can install. 2.1.231 exists for other platforms but not linux-x64 yet — this platform is lagging the release, not up to date. Use --all-platforms for the full matrix, or --platform <id> to check a specific one."
}
3. Add the switches, and advertise them in the output. --all-platforms for the full matrix and --platform <id> to target a specific one. The _hint matters as much as the flags: an AI reads the command output, not the skill file, so the output itself has to say that a broader query is available and what it would mean.
Suggested _hint when the platform genuinely is current and matches everyone else: state that plainly so the AI stops rather than hunting for a phantom update.
Also worth considering
extensions update succeeding with "update requested" when the gallery has nothing newer for this platform is indistinguishable from a real update being queued. If the gallery has no installable candidate, saying so — rather than reporting a queued update that will never land — would remove the other half of the confusion.
Workaround for now
Install the VSIX by hand from the native API. Note the env -u — the shell inherits CODE_SERVER_PARENT_PID from the extension host and code-server's CLI otherwise dies with error not spawned with IPC:
curl -sL -o cc.vsix "https://open-vsx.org/api/Anthropic/claude-code/linux-x64/2.1.231/file/[email protected]"
env -u CODE_SERVER_PARENT_PID -u VSCODE_IPC_HOOK_CLI -u VSCODE_ESM_ENTRYPOINT \
/usr/bin/code-server --install-extension ./cc.vsix \
--extensions-dir ~/.local/share/code-server/extensions --force
That documented-nowhere env -u requirement might itself be worth folding into an extensions install --vsix <path|url> verb.