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 for the Antigravity plugin configuration if missing
  • seeds antigravity.json if missing
  • creates a minimal package.json in the config dir if needed
  • installs opencode-antigravity-auth@beta in the background if not already present

The design choice here is subtle but important: plugin installation is tied to persistent config state, not baked irreversibly into the container runtime path.

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