You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Its AMD64 image reports version 1.0.0.156 and creation time 2025-12-08, while the pinned Volcengine 1.11.0 tag resolves to the expected v1.11.0 image.
Runtime verification
Using the published v1.11.0 AMD64 image with SANDBOX_API_KEY configured:
Request without a key: HTTP 401
Request with the correct key: HTTP 200
API, VNC, and Code Server routes are protected
Shell, file persistence, browser navigation, and screenshot endpoints work
This confirms that the v1.11.0 image supports the feature even though the tagged README does not document it.
Why this is confusing
Users following different official image examples can receive different runtime capabilities depending on whether they use GHCR latest, Volcengine latest, or the pinned 1.11.0 tag.
Related reports include #160, #210, and #220. PR #217 pins the mainland-China example to 1.11.0, which avoids the stale latest tag but does not clarify or repair the tag mapping itself.
Request
Could the maintainers please clarify the intended release and image-tag policy and consider:
documenting API key support in the v1.11.0 release notes;
fixing the Volcengine latest tag;
documenting whether latest is expected to track the latest GitHub release;
recommending pinned release tags or digests for production deployments;
optionally publishing a v1.11.1 patch release if a new immutable release is needed to synchronize the security documentation.
Summary
There are several inconsistencies between the latest GitHub release, the tagged documentation, and the published container tags:
v1.11.0tagged README does not documentSANDBOX_API_KEY.SANDBOX_API_KEYwas documented onmainin docs: add sandbox API key example #216, three days after the v1.11.0 release.latestcurrently resolves to v1.11.0, but the Volcengine mirrorlatestresolves to an older image reporting version1.0.0.156.Verified image metadata
Checked on 2026-08-20.
GHCR
latestand the pinned v1.11.0 image currently resolve to this multi-platform digest:sha256:6328d7fd2f0ff0b4c147c3d05b3df1ce331f4a482eb6e550ecd64ed1fcf906e7The v1.11.0 AMD64 manifest is:
sha256:9a597aaa3716aca2fd42a517ceedc41063e5ceedcef43eb68bf7c059c0128b7aThe Volcengine mirror
latestcurrently resolves to:sha256:742062f99915e5495df8d4bfeaf40a93197c87c7c47b4e2407cd2b6356df8f48Its AMD64 image reports version
1.0.0.156and creation time2025-12-08, while the pinned Volcengine1.11.0tag resolves to the expected v1.11.0 image.Runtime verification
Using the published v1.11.0 AMD64 image with
SANDBOX_API_KEYconfigured:This confirms that the v1.11.0 image supports the feature even though the tagged README does not document it.
Why this is confusing
Users following different official image examples can receive different runtime capabilities depending on whether they use GHCR
latest, Volcenginelatest, or the pinned1.11.0tag.Related reports include #160, #210, and #220. PR #217 pins the mainland-China example to
1.11.0, which avoids the stalelatesttag but does not clarify or repair the tag mapping itself.Request
Could the maintainers please clarify the intended release and image-tag policy and consider:
latesttag;latestis expected to track the latest GitHub release;Thanks.