TazPod Provisioning and Dotfiles

The personality of a TazPod shell is defined less by Docker itself and more by dotfiles/.bashrc plus the persistent directories under /workspace/.tazpod/.

Persistent Tool State Under .tazpod/

The operator tool state that should survive container recreation is kept in:

  • /workspace/.tazpod/.pi
  • /workspace/.tazpod/.omp
  • /workspace/.tazpod/.gemini
  • /workspace/.tazpod/.claude
  • /workspace/.tazpod/.aws
  • /workspace/.tazpod/.opencode

These are created by vault.SetupIdentity() and then wired into the shell by .bashrc.

The .bashrc Provisioning Logic

The bashrc logic ensures that the runtime home directory points back to persistent project state.

Examples:

  • ~/.config/opencode -> /workspace/.tazpod/.opencode/config
  • ~/.local/share/opencode -> /workspace/.tazpod/.opencode/data
  • ~/.local/state/opencode -> /workspace/.tazpod/.opencode/state
  • ~/.cache/opencode -> /workspace/.tazpod/.opencode/cache

This is the real reason OpenCode config survives container recreation even though the container filesystem itself is disposable.

Auto-Seeding OpenCode

The current bashrc now seeds and self-heals the OpenCode integration:

  • creates tui.json if missing
  • seeds opencode.json with standard Gemini CLI models if missing
  • creates a minimal package.json in the config dir if needed

The design choice here is subtle but important: plugin installation is tied to persistent config state, not baked irreversibly into the container runtime path. The opencode-antigravity-auth@beta plugin was removed (2026-05-07) due to ToS violation risk.

Why Dotfiles Matter Here

In TazPod, dotfiles are not cosmetic. They are the control plane that reconnects disposable containers to persistent operator state.

Without this layer:

  • OpenCode state would reset on every new container
  • AI tool configs would fragment between RAM, home, and workspace
  • the operator would constantly have to reconstruct the same environment by hand

See Also