Summary
openAB currently does not patch the Gemini CLI first-run initialization issue in the image/chart, which is the right direction since the root cause is upstream in gemini-cli.
However, new users who deploy Gemini-backed openAB can still hit this on first install and may not know how to work around it during deployment.
It would be helpful to have a dedicated issue/docs entry that explains the symptom, root cause, and supported installation-time workarounds.
Upstream issue
User-visible symptom
On first startup in ephemeral/containerized environments, Gemini CLI can fail because ~/.gemini and/or ~/.gemini/projects.json are not initialized yet.
Observed failure modes include:
ENOENT while saving the registrySyntaxError: Unexpected end of JSON input if the file exists but is empty
What should be documented
A troubleshooting/install-time workaround section for Gemini deployments, covering:
1. ECS / Fargate workaround
Document the container command override pattern, e.g. seeding:
mkdir -p /home/node/.gemini && echo '{}' > /home/node/.gemini/projects.json && exec openab /etc/openab/config.tomlbefore starting openab.
2. Helm / Kubernetes workaround
Document the init-container + shared volume pattern for seeding /home/node/.gemini.
However, there is one current gap:
The chart does not appear to expose passthrough fields like:
extraInitContainersextraVolumesextraVolumeMounts
in charts/openab/templates/deployment.yaml yet.
So either:
- the docs should wait until those chart fields exist, or
- a small chart enhancement should land first, then docs can point users to the supported values-based workaround.
Suggested outcome
One of:
- Add a docs/troubleshooting section in
docs/gemini.md
- Add a general troubleshooting note in
README.md linking to docs/gemini.md
- Optionally add chart support for
extraInitContainers / extraVolumes / extraVolumeMounts, then document the Helm values workaround
Why this matters
Even if openAB should not carry the workaround in its image, users still need a clear and discoverable installation-time path forward until the upstream Gemini CLI fix lands.
Summary
openABcurrently does not patch the Gemini CLI first-run initialization issue in the image/chart, which is the right direction since the root cause is upstream ingemini-cli.However, new users who deploy Gemini-backed openAB can still hit this on first install and may not know how to work around it during deployment.
It would be helpful to have a dedicated issue/docs entry that explains the symptom, root cause, and supported installation-time workarounds.
Upstream issue
User-visible symptom
On first startup in ephemeral/containerized environments, Gemini CLI can fail because
~/.geminiand/or~/.gemini/projects.jsonare not initialized yet.Observed failure modes include:
ENOENTwhile saving the registrySyntaxError: Unexpected end of JSON inputif the file exists but is emptyWhat should be documented
A troubleshooting/install-time workaround section for Gemini deployments, covering:
1. ECS / Fargate workaround
Document the container command override pattern, e.g. seeding:
before starting
openab.2. Helm / Kubernetes workaround
Document the init-container + shared volume pattern for seeding
/home/node/.gemini.However, there is one current gap:
The chart does not appear to expose passthrough fields like:
extraInitContainersextraVolumesextraVolumeMountsin
charts/openab/templates/deployment.yamlyet.So either:
Suggested outcome
One of:
docs/gemini.mdREADME.mdlinking todocs/gemini.mdextraInitContainers/extraVolumes/extraVolumeMounts, then document the Helm values workaroundWhy this matters
Even if openAB should not carry the workaround in its image, users still need a clear and discoverable installation-time path forward until the upstream Gemini CLI fix lands.