When creating a new sprite and attempting to use Gemini CLI, the experience is broken.
Gemini will attempt to auto-upgrade, resulting in something else breaking, and gemini command no longer being found by nvm.
The CLI throws errors due to looking for Git-related metadata
This seems to cause the UI to thrash back and forth (unless you minimize), but even by attempting to skip through setting ENV for API token, it just gets stuck.
This seems an odd experience for a sandbox with pre-installed tools. Can collect some more logs and examples - but it makes me wonder if Gemini is configured correctly?
The TUI was not streamed to my local terminal, eventually if I keep re-trying, I get that working but I needed to retry a few times and maybe also log out and log back in.
Somehow similar experience, sometimes with uv sync (downloading python packages) the UI was frozen, and uv was not making visible progresses.
Eventually after log out and log back in, I tried again and the packages where installed correctly.
Thanks for the details. These tools are moving very quickly, as I’m sure you know. We are working on some ways to make keeping them updated easier for new sprites and existing sprites. I don’t have a timeline for this work but these details are a big help.
I’ve been experimenting with the process you’ve used basically which is to install it myself. That’s not the experience we want sprite users to have but it is a workaround for now.
This seemed to get around almost all of the glitching. It did require a fix on the ~/.zshrc to persist…but once this was done, it seemed to work just fine with the sprite capabilities (checkpointing etc). It did get confused slightly from time to time on checkpointing and missed the service start magic (port forwarding to 8080)…but that is mainly b/c I didn’t understand how it works…so now I think it can be resolved with a little more forceful context work up front.