Sprites.dev Gemini seems broken

When creating a new sprite and attempting to use Gemini CLI, the experience is broken.

  1. Gemini will attempt to auto-upgrade, resulting in something else breaking, and gemini command no longer being found by nvm.
  2. The CLI throws errors due to looking for Git-related metadata
  3. 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?

Repro

  • sprite create test12345
  • gemini (will see lots of terminal flashing)
  • exit
  • gemini

attempting to reinstall or upgrade takes a very long time.

You mention that attempting to reinstall takes a long time. Did gemini work after you did the reinstall?

Here’s where I’ve gotten to

  1. New sprite
  2. npm install -g @google/gemini-cli@latest
  3. gemini
  4. paste in API key

That seems to work reasonably well - I checkpointed to make sure I could repro it and it seemed to work.

I also used gh to auth to my Github so I could pull down some repos to play around with.

Here’s what goes haywire

If settings.json.general.checkpointing.enabled = true the UI goes haywire with this

If you set checkpointing to false, then it does this

It just gets stuck in the Initializing step and can’t do anything

Similar issue, but with opencode.

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.

Manual installation is totally fine to get unblocked. Is the only additional context that would need inclusion in the ~/.gemini folder?

Perhaps an extra doc page showing what lives where for preinstalled tools would be useful.

I was able to get around this with

  • npm install @latest
  • checkpointing: false
  • GEMINI_SYSTEM_MD=false

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.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.