build(templates): use shared sandbox runtime images#228
Conversation
wanghaojie124
commented
Jun 23, 2026
wanghaojie124
commented
- use shared sandbox runtime images
| if r.deps.SandboxProviderName != nil { | ||
| provider = strings.TrimSpace(r.deps.SandboxProviderName()) | ||
| } | ||
| if provider != config.DockerProvider && provider != config.BoxLiteProvider { |
There was a problem hiding this comment.
This limits the sandbox-tools mount to docker and boxlite, which means the new csgclaw-cli refresh path never applies to the csghub provider. If the shared runtime image no longer guarantees a CLI version that stays in lockstep with the server, csghub sandboxes will keep running an older CLI even though the builtin workspaces and skills here still depend on csgclaw-cli. If csghub remains a supported provider, consider giving it an update path too, or documenting that the shared image itself must provide the compatible CLI.
| } | ||
| if !strings.EqualFold(currentRepo, latestRepo) { | ||
| if !isLegacyPicoClawRepositoryUpgrade(currentRepo, latestRepo) { | ||
| if !isCompatibleRepositoryUpgrade(currentRepo, latestRepo) { |
There was a problem hiding this comment.
This broadens the repo-family migration check, but the upgrade decision for the already-migrated case still falls through to the same-repository branch below, where currentTag is compared against the template version. After this PR switches builtin refs to shared date-based tags such as picoclaw:2026.6.23 while version remains 0.1.x, a later upgrade from one shared tag to a newer shared tag will be treated as not outdated and the upgrade prompt will stop firing. Consider comparing against the tag from latest.image instead, or keeping version in the same comparable format as the shared image tag.
2 participants
