# pi-devbox environment configuration # Copy this file to .env and fill in your values: # cp .env.example .env # ── Workspace ──────────────────────────────────────────────────────── # Path on host to mount as /workspace in the container WORKSPACE_PATH=~/projects # Path to SSH keys on host SSH_KEY_PATH=~/.ssh # ── MemPalace memory (local by default) ─────────────────────────── # By default the mempalace.ts extension spawns a LOCAL mempalace-mcp stdio # server (palace at ~/.mempalace). Uncomment the devbox-palace volume in # docker-compose.yml to persist it across container recreation — that one # volume now covers the mined conversation transcripts too, since the pi and # opencode feeders stage inside the palace root (/pi-stage), so # the staged files and the palace dedup keys pointing at them cannot be # separated. # # To instead share ONE MemPalace across containers/harnesses (pi + opencode # + native), set the URL below. When set, the extension connects over HTTP # and NO local mempalace-mcp is spawned; the devbox-palace volume is then # irrelevant. MEMPALACE_REMOTE_TOKEN, if set, is sent as a bearer token. # # Serve it with: mempalace serve --host 172.17.0.1 --port 8765 # # NOT `mempalace-mcp --transport http --host 0.0.0.0`: `serve` is the turnkey # wrapper that mints/keeps a bearer token (0600, passed via env so it stays out # of `ps`) and can terminate TLS. Two binds to avoid: # 0.0.0.0 - exposes the palace to the whole LAN. # 127.0.0.1 - behind a tunnel this 403s every proxied request (the Host pin # is only enforced on loopback binds) AND silently starts with # no token at all, since auto-minting is gated on the bind being # non-loopback. Bind the docker0 gateway: reachable from the host # and its containers (so a newt/proxy container works), not from # the LAN. Set MEMPALACE_MCP_HTTP_TOKEN explicitly server-side. # MEMPALACE_REMOTE_URL=https://mempalace.example.com/mcp # MEMPALACE_REMOTE_TOKEN= # ── MemPalace: automatic capture of pi sessions ─────────────────────── # The mempalace.ts extension feeds this container's pi transcripts into the # palace by itself: on session_shutdown, and on a debounced agent_settled so a # crash loses at most one window rather than the whole session. The entrypoint # also runs a catch-up at container start, which is the only thing that can # recover transcripts after a hard kill (no handler runs on SIGKILL). # Nothing below is required for the local-palace case; the defaults work. # # MEMPALACE_FEED=0 # disable automatic capture entirely # MEMPALACE_FEED_DEBOUNCE_MS=600000 # min gap between mid-session feeds (10 min) # MEMPALACE_FEED_WING=wing_conversations # # REMOTE PALACE ONLY (MEMPALACE_REMOTE_URL set above): the palace is on another # host, and `mempalace_mine` resolves its source path in the SERVER process, so # the server cannot see this container's transcripts. The feeder therefore # rsyncs its staged exports into a per-device inbox on the palace host and asks # the server to mine its own local copy. Without MEMPALACE_PI_SSH_TARGET the # feeder is skipped (a remote palace with no inbox has nothing to mine). # MEMPALACE_PI_SSH_TARGET where to rsync to, as user@host:path # MEMPALACE_PI_REMOTE_PATH what that inbox is called ON THE SERVER — must be # the container path if the server runs in Docker # (see docker-compose.mempalace.yml) # MEMPALACE_PI_DEVICE inbox subdirectory for this machine (default: hostname) # MEMPALACE_PI_SSH_TARGET=user@palace-host:/srv/mempalace-feed # MEMPALACE_PI_REMOTE_PATH=/data/feed # MEMPALACE_PI_DEVICE= # ── LAN access from the container (host-OS-agnostic) ───────────────── # On VM-backed hosts (macOS OrbStack / Docker Desktop) the container can't # reach the host's directly-attached LAN peers by default. The entrypoint # then sets up the host as an SSH jump (use the `dssh` alias). Reach the host # with `dssh host`; for named LAN peers put `ProxyJump host` overrides in a # host-owned ~/.config/devbox-shell/ssh-lan.conf (bind-mounted in) rather than # editing ~/.ssh/config. On native Linux Docker the LAN is reachable directly # and this is a no-op. # See the opencode-devbox README for the full walkthrough. # # DEVBOX_LAN_ACCESS: auto (default) | jump | off # DEVBOX_LAN_ACCESS=auto # HOST_SSH_USER: your username on the host (required for the jump). On first # start the entrypoint prints the public key to authorize on the host. # HOST_SSH_USER= # DEVBOX_HOST_ALIAS: host hostname to reach (default host.docker.internal). # DEVBOX_HOST_ALIAS=host.docker.internal # DEVBOX_LAN_AUTOJUMP_PRIVATE: 1 = ProxyJump any private (RFC1918) IP through # the host, so bare `dssh user@` works on whatever LAN you're roaming on. # DEVBOX_LAN_AUTOJUMP_PRIVATE=0 # ── pi-atelier (TUI sidebar) ───────────────────────────────────────── # The image vendors pi-atelier at a pinned, audited tag and registers it on # container start. Set to 0 to opt out: the entrypoint then removes it from # pi's `packages[]` instead of registering it. This lives here rather than # being a `pi uninstall` because a broken TUI extension's failure mode is # "pi will not start", which you cannot fix from inside pi. # DEVBOX_ATELIER=1 # ── Git Configuration ──────────────────────────────────────────────── # Set BOTH. If unset, every repo inside the container fails with # "Author identity unknown" on first commit, and an agent asked to commit # will guess an identity from git log — often the wrong one. The e-mail is # per-machine (work machines use the corporate address, personal machines the # private one), so it belongs in this per-machine .env, never in a skill or a # repo-local override. Consumed by entrypoint-user.sh -> ~/.gitconfig, which is # NOT persistent across container recreate — this file is the source of truth. GIT_USER_NAME= GIT_USER_EMAIL= # ── Gitea (for gitea-mcp MCP server) ──────────────────────────────── # GITEA_ACCESS_TOKEN= # GITEA_HOST=https://gitea.example.com # ── GitHub (optional, for GitHub MCP / git operations) ─────────────── # GITHUB_PERSONAL_ACCESS_TOKEN= # ── AWS (optional, for AWS CLI / Bedrock) ──────────────────────────── # AWS_REGION=eu-west-1 # AWS_PROFILE=default # AWS_ACCESS_KEY_ID= # AWS_SECRET_ACCESS_KEY= # ── Skillset (agent skills and instructions) ───────────────────────── # If you have a skillset repo, the entrypoint auto-deploys skills and # instructions on container start using relative symlinks. # Detection is automatic if the skillset lives at WORKSPACE_PATH/skillset. # SKILLSET_CONTAINER_PATH= # ── Locale ─────────────────────────────────────────────────────────── # LANG=sv_SE.UTF-8 # LANGUAGE=sv_SE:sv # LC_ALL=sv_SE.UTF-8