TanStack AI version
@tanstack/ai@0.58.0, @tanstack/ai-sandbox@0.5.12, @tanstack/ai-sandbox-docker@0.3.2 (npm latest versions when tested).
Framework/Library version
No UI framework. Bun 1.4.2 on Linux.
Describe the bug and the steps to reproduce it
Changing only gitSource({ auth: { token } }) changes the sandbox instance key, even with the same threadId, sandbox ID, repository, and reuse: 'thread'.
This comes up with GitHub App installation tokens, which expire after one hour. Renewing the token changes the lookup key, so a later run cannot find the previous sandbox record even if its container is still available.
To reproduce, download the three files from the gist below and run:
The script computes keys before and after changing a Git token, then does the same for a workspace secret. It does not create a sandbox or make any network requests; no Docker daemon or real credentials are needed to run it.
Actual output:
Git token rotation changes key: true
Workspace secret rotation changes key: false
Expected: both comparisons return false. Renewing a credential with equivalent access should not by itself invalidate sandbox reuse.
In computeWorkspaceHash(), workspace.secrets is excluded, but source.auth.token remains in the hashed object. gitSource accepts a string token and bootstrap forwards it directly to handle.git.clone().
The provisioning guide documents SecretRef authentication for gitSkill, but the main workspace source does not accept it. Is there a supported way to use rotating credentials for the main Git source without changing its sandbox key?
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
https://gist.github.com/HCaupert/c42a7faf5b38dec95d43b0aa98abc501
Terms & Code of Conduct
TanStack AI version
@tanstack/ai@0.58.0,@tanstack/ai-sandbox@0.5.12,@tanstack/ai-sandbox-docker@0.3.2(npm latest versions when tested).Framework/Library version
No UI framework. Bun 1.4.2 on Linux.
Describe the bug and the steps to reproduce it
Changing only
gitSource({ auth: { token } })changes the sandbox instance key, even with the samethreadId, sandbox ID, repository, andreuse: 'thread'.This comes up with GitHub App installation tokens, which expire after one hour. Renewing the token changes the lookup key, so a later run cannot find the previous sandbox record even if its container is still available.
To reproduce, download the three files from the gist below and run:
The script computes keys before and after changing a Git token, then does the same for a workspace secret. It does not create a sandbox or make any network requests; no Docker daemon or real credentials are needed to run it.
Actual output:
Expected: both comparisons return
false. Renewing a credential with equivalent access should not by itself invalidate sandbox reuse.In
computeWorkspaceHash(),workspace.secretsis excluded, butsource.auth.tokenremains in the hashed object.gitSourceaccepts a string token and bootstrap forwards it directly tohandle.git.clone().The provisioning guide documents
SecretRefauthentication forgitSkill, but the main workspace source does not accept it. Is there a supported way to use rotating credentials for the main Git source without changing its sandbox key?Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
https://gist.github.com/HCaupert/c42a7faf5b38dec95d43b0aa98abc501
Terms & Code of Conduct