Update docs for named volume config, skillset auto-deploy, opencode.jsonc

- README: rewrite config/skills sections for named volume and auto-deploy,
  add Context7 MCP docs, update all opencode.json→opencode.jsonc refs,
  add SKILLSET_CONTAINER_PATH to env var table
- CHANGELOG: add v1.14.32b entry documenting breaking changes and features
- AGENTS.md: update file roles, add skillset and config volume conventions
- DOCKER_HUB.md: regenerated (drop Context7 and Shell defaults sections
  to stay within 25KB Docker Hub limit)
- generate-dockerhub-md.py: add Context7 (drop) and Shell defaults (drop)
  to SECTION_RULES

AGENTS.md

@@ -8,8 +8,8 @@ Docker image packaging [opencode](https://opencode.ai) into a production-ready d
 
 - `Dockerfile` — single multi-stage build for both variants. OMOS variant is controlled by `INSTALL_OMOS=true` build arg; mempalace is controlled by `INSTALL_MEMPALACE` (default `true`). All GitHub-sourced binaries are pinned with version ARGs.
 - `entrypoint.sh` — runs as root: UID/GID adjustment, SSH permissions, volume ownership fixes (skipped via `.devbox-owner` sentinel when ownership is already correct). Then drops to developer via gosu.
-- `entrypoint-user.sh` — runs as developer: git config, opencode.json generation (delegated to `generate-config.py`), OMOS setup.
+- `entrypoint-user.sh` — runs as developer: git config, opencode.jsonc generation (delegated to `generate-config.py`), skillset auto-deploy from mounted skillset repo, OMOS setup.
-- `rootfs/usr/local/lib/opencode-devbox/generate-config.py` — generates `~/.config/opencode/opencode.json` from env vars. Never overwrites an existing config. Auto-registers MCP servers for detected tools (mempalace via the `mempalace-mcp` entry point, gitea-mcp).
+- `rootfs/usr/local/lib/opencode-devbox/generate-config.py` — generates `~/.config/opencode/opencode.jsonc` from env vars. Never overwrites an existing config (checks both `.json` and `.jsonc`). Auto-registers MCP servers for detected tools (mempalace via `mempalace-mcp`, gitea-mcp, context7 remote endpoint).
 - `scripts/smoke-test.sh` — post-build image verification. Asserts binary presence, opencode startup, entrypoint correctness, config generation idempotency, and image size thresholds. Used by both CI workflows.
 - `scripts/generate-dockerhub-md.py` — generates `DOCKER_HUB.md` from `README.md` using explicit section rules. `--check` fails if the committed file is out of sync (enforced by the `validate` workflow).
 - `DOCKER_HUB.md` — **auto-generated** from README. Do not edit directly. Pushed to Docker Hub description via CI API call. Must stay under 25 kB. Short description field must be ≤100 bytes.
@@ -37,8 +37,10 @@ When bumping the opencode version, also bump `OPENCODE_VERSION` in `Dockerfile`
 - **GitHub/Gitea-sourced binaries float by default** — gosu, fzf, git-lfs, nvim, bat, eza, zoxide, uv, gitea-mcp, Go, oh-my-opencode-slim all default to `latest`. Each build-time install step reads the `/releases/latest` Location redirect (or the go.dev JSON feed for Go) and derives the concrete version. Use the same `ARCH` case-switch pattern for multi-arch support (amd64/arm64). Intentional pins: `OPENCODE_VERSION` (drives the image tag), `NODE_VERSION=22` (major pin), `DEBIAN_VERSION=trixie-slim` (OS base). Adding a new upstream tool: follow the existing floated-version pattern, don't hardcode a specific tag.
 - **Resolved versions are logged by the smoke test** — `scripts/smoke-test.sh` prints a "Resolved component versions" table as its first step. CI logs always capture what got baked into a given image even when ARGs default to `latest`.
 - **Shell scripts use `set -euo pipefail`** — both entrypoints are strict. Errors in volume chown or SSH permission operations are intentionally suppressed with `|| true`.
-- **MemPalace install path** — installed via `uv tool install` into `/opt/uv-tools/mempalace/`. Both the `mempalace` CLI and the `mempalace-mcp` MCP server binary are shipped as entry points by the mempalace package itself and placed on PATH by uv as shims whose shebangs point at the venv's Python. No hand-rolled wrapper is needed. Do not use `pip install --break-system-packages` — that was the previous approach and has been removed. Do not use `["python3", "-m", "mempalace.mcp_server"]` in `opencode.json` — system Python can't import from the uv venv.
+- **MemPalace install path** — installed via `uv tool install` into `/opt/uv-tools/mempalace/`. Both the `mempalace` CLI and the `mempalace-mcp` MCP server binary are shipped as entry points by the mempalace package itself and placed on PATH by uv as shims whose shebangs point at the venv's Python. No hand-rolled wrapper is needed. Do not use `pip install --break-system-packages` — that was the previous approach and has been removed. Do not use `["python3", "-m", "mempalace.mcp_server"]` in `opencode.jsonc` — system Python can't import from the uv venv.
-- **generate-config.py idempotency** — the script MUST never overwrite an existing `opencode.json`. Users bind-mount their config directory or persist it across container recreations; accidentally clobbering that file would destroy hand-edits. The smoke test asserts this.
+- **generate-config.py idempotency** — the script MUST never overwrite an existing `opencode.jsonc` or legacy `opencode.json`. Config persists in the `devbox-opencode-config` named volume; accidentally clobbering that file would destroy hand-edits. The smoke test asserts this.
+- **Skillset auto-deploy** — on every container start, `entrypoint-user.sh` looks for a skillset repo (detection order: `$SKILLSET_CONTAINER_PATH` → `$HOME/skillset` → `/workspace/skillset`) and runs `deploy-skills.sh --bootstrap --prune-stale`. This creates relative symlinks in `~/.agents/skills/` and `~/.config/opencode/instructions/`. Do NOT bind-mount `~/.agents/skills/` from the host — the container manages its own skills with relative symlinks that differ from the host's. The named volume `devbox-opencode-config` persists the deployed config across restarts.
+- **Config persistence via named volume** — `devbox-opencode-config` is a Docker named volume mounted at `~/.config/opencode/`. It is NOT a host bind mount by default. This separation allows both native and containerized opencode to coexist on the same machine without symlink conflicts. Users who need to override can replace the named volume with a host bind mount in their compose file.
 - **Docker Hub description update** — uses `/v2/auth/token` endpoint (not the deprecated `/v2/users/login`). Auth uses `identifier`/`secret` fields, returns `access_token`, sent as `Bearer`. Short description must be ≤100 bytes.
 
 ## CI quirks

CHANGELOG.md

@@ -6,6 +6,16 @@ Tags follow `v{opencode_version}[letter]` — bare tag for the first build on a
 
 ---
 
+## v1.14.32b — 2026-05-02
+
+**Named volume for opencode config, skillset auto-deploy.**
+
+- **Breaking:** `~/.config/opencode/` now uses a named volume (`devbox-opencode-config`) instead of a host bind mount. The container's config, skills, and instructions are independent from the host. Users who relied on the bind mount should either re-add it explicitly in their compose file (overriding the volume) or migrate hand-edits into the container.
+- **Breaking:** `~/.agents/skills/` is no longer bind-mounted from the host. The container manages its own skills directory — the entrypoint deploys skills from the skillset repo on each start.
+- **Feature:** Skillset auto-deploy on container start. The entrypoint runs `deploy-skills.sh --bootstrap --prune-stale` from the first skillset repo found at: `$SKILLSET_CONTAINER_PATH` → `~/skillset` → `/workspace/skillset`. Creates relative symlinks that resolve inside the container regardless of host path layout. Idempotent.
+- **Env:** New `SKILLSET_CONTAINER_PATH` env var for specifying skillset repo location inside the container when it's not at `/workspace/skillset`.
+- **Docs:** README updated for named volume config, skillset auto-deploy, Context7 MCP server, `opencode.jsonc` references.
+
 ## v1.14.32 — 2026-05-02
 
 Bump opencode to 1.14.32.

DOCKER_HUB.md

@@ -69,9 +69,6 @@ Bind-mounted directories must exist on the host before starting the container. D
 ```bash
 # Required: workspace for your projects
 mkdir -p ~/projects
-
-# If mounting opencode config (recommended for persistent settings)
-mkdir -p ~/.config/opencode
 ```
 
 ### Connecting to the container
@@ -145,28 +142,34 @@ docker compose exec -u developer devbox aws --version
 | `OMOS_TMUX` | Enable tmux pane integration for OMOS | `false` |
 | `OMOS_SKILLS` | Install OMOS recommended skills on first run | `true` |
 | `OMOS_RESET` | Force regenerate OMOS config on next start | `false` |
+| `SKILLSET_CONTAINER_PATH` | Path to skillset repo inside container (for auto-deploy when not at /workspace/skillset) | Auto-detect |
 
 ### Custom opencode config
 
-For full control over opencode settings (MCP servers, custom models, and — on the OMOS variant — oh-my-opencode-slim agents), mount the entire config directory from the host:
+Opencode configuration is persisted automatically via the named volume `devbox-opencode-config`. This volume is mounted at `/home/developer/.config/opencode` by default — no host directory setup required. All changes to `opencode.jsonc`, skills, and (on the OMOS variant) `oh-my-opencode-slim.json` survive container recreation.
+
+When an existing `opencode.jsonc` is found in the volume, the `OPENCODE_PROVIDER` auto-config is skipped.
+
+**Alternative: host bind-mount** — if you specifically want to share config from the host (e.g. to version-control it or sync across machines), replace the named volume with a bind mount:
 
 ```yaml
 volumes:
   - ~/.config/opencode:/home/developer/.config/opencode
 ```
 
-This persists all configuration changes across container restarts, including `opencode.json`, skills, and (on the OMOS variant) `oh-my-opencode-slim.json`. When an existing `opencode.json` is found, the `OPENCODE_PROVIDER` auto-config is skipped.
+> **Portability note:** The mounted config runs inside a Linux container. Any absolute paths inside `opencode.jsonc` (for example, host-specific `plugin` entries like `file:///usr/local/lib/node_modules/...` or `file:///opt/homebrew/...`) will not resolve inside the container. Prefer bare package specifiers (e.g. `"oh-my-opencode-slim"`) that resolve via `node_modules` lookup, which works on both macOS and Linux hosts.
-
-> **Portability note:** The mounted config runs inside a Linux container. Any absolute paths inside `opencode.json` (for example, host-specific `plugin` entries like `file:///usr/local/lib/node_modules/...` or `file:///opt/homebrew/...`) will not resolve inside the container. Prefer bare package specifiers (e.g. `"oh-my-opencode-slim"`) that resolve via `node_modules` lookup, which works on both macOS and Linux hosts.
 
 ### Custom skills
 
-Mount agent skills from the host:
+Skills are deployed automatically from a skillset repo on container start. The entrypoint detects the skillset location in this order:
 
-```yaml
+1. `SKILLSET_CONTAINER_PATH` env var (explicit path to skillset repo inside container)
-volumes:
+2. `~/skillset` mount (if present)
-  - ~/.agents/skills:/home/developer/.agents/skills:ro
+3. `/workspace/skillset` fallback (if your workspace contains a `skillset/` directory)
-```
+
+When a skillset repo is detected, its skills are symlinked into `~/.agents/skills/` automatically. No manual configuration needed.
+
+> **Warning:** Do not bind-mount a host `~/.agents/skills` directory directly into the container. This conflicts with the symlink-based auto-deploy mechanism and causes broken skill references.
 
 ### Neovim configuration
 
@@ -414,7 +417,7 @@ Without the volume, palace data lives in the container's writable layer and is l
 
 ### MCP integration with opencode
 
-Add mempalace as an MCP server in your `opencode.json` (inside `~/.config/opencode/`):
+Add mempalace as an MCP server in your `opencode.jsonc` (inside `~/.config/opencode/`):
 
 ```json
 {
@@ -498,7 +501,7 @@ The image includes the [official Gitea MCP server](https://gitea.com/gitea/gitea
    GITEA_ACCESS_TOKEN=your_token_here
    ```
 
-3. Enable the gitea MCP server in your `opencode.json`:
+3. Enable the gitea MCP server in your `opencode.jsonc`:
    ```json
    {
      "mcp": {
@@ -516,51 +519,6 @@ The image includes the [official Gitea MCP server](https://gitea.com/gitea/gitea
 
 The server is installed but disabled by default — it requires authentication to be useful.
 
-## Shell defaults
-
-The image ships a baked `.bash_aliases` and `.inputrc` with quality-of-life defaults. On first container start they are copied from `/etc/skel-devbox/` into `/home/developer/` **only if the target file does not already exist** — so host bind-mounts and any version you've customized inside the container are never overwritten on upgrade.
-
-Defaults you get out of the box:
-
-- **Prefix history search** on Up/Down arrows (type `git `, press Up, walk back through prior `git ...` commands only). Ctrl-Up / Ctrl-Down still step through full history.
-- **Persistent history** — `$HISTFILE` points at `~/.cache/bash/history`, backed by the `devbox-shell-history` named volume so history survives container recreation. Timestamps, 100 000 entries, dedup.
-- **Case-insensitive tab completion**, coloured completion lists, `show-all-if-ambiguous`.
-- **Aliases** — `ls`/`ll`/`la` use `eza`, `cat` uses `bat`, `gs`/`gd`/`gl` for git, safe `rm`/`mv`/`cp`.
-- **Integrations** — `zoxide` (`z <fragment>` to jump), `fzf` Ctrl-R / Ctrl-T key bindings.
-- **Prompt marker** — `[devbox]` prefix so it's always obvious you're inside the container.
-
-### Overriding the defaults
-
-**Option A — bind-mount host files.** Uncomment the bind-mount lines in `docker-compose.yml`:
-
-```yaml
-- ~/.bash_aliases:/home/developer/.bash_aliases:ro
-- ~/.inputrc:/home/developer/.inputrc:ro
-```
-
-> **Single-file bind-mount caveat (all platforms):** Docker bind-mounts the file's **inode**, not its path. When editors like vim, nvim, VS Code, or `sed -i` save a file, they write to a temp file and `rename()` it over the original — creating a new inode. The container stays pinned to the old (now unlinked) inode and never sees the update. This is a kernel limitation ([Docker #15793](https://github.com/moby/moby/issues/15793)), not fixable by Docker. Append-only writes (`echo "alias foo=bar" >> file`) are safe because they modify the same inode. **Workaround:** mount the parent directory instead of the single file (e.g. `~/.config/devbox-shell:/home/developer/.config/devbox-shell:ro`) and source files from there.
-
-**Option B — customize inside the container.** Just edit `~/.bash_aliases` or `~/.inputrc` as normal. Pair this with a bind-mount or named volume on the home dir if you want the edits to survive container recreation.
-
-### Restoring or diffing defaults
-
-The skel files remain available inside every container at `/etc/skel-devbox/`. Useful commands:
-
-```bash
-# See what the image currently ships
-cat /etc/skel-devbox/.bash_aliases
-
-# Diff your current config against the upstream defaults
-diff ~/.bash_aliases /etc/skel-devbox/.bash_aliases
-
-# Reset to the baked defaults
-cp /etc/skel-devbox/.bash_aliases ~/.bash_aliases
-
-# …or delete the file and recreate the container — the entrypoint
-# copies from /etc/skel-devbox/ on next start if the target is absent
-rm ~/.bash_aliases
-```
-
 ## Architecture
 
 ```
@@ -598,9 +556,9 @@ Container (Debian trixie)
 | `/home/developer/.rustup` | Named volume `devbox-rustup` (if configured) | ✅ Yes | Rust toolchains |
 | `/home/developer/.cargo` | Named volume `devbox-cargo` (if configured) | ✅ Yes | Cargo binaries, registry cache |
 | `/home/developer/.vscode-server` | Named volume `devbox-vscode` (if configured) | ✅ Yes | VS Code server and extensions |
-| `/home/developer/.config/opencode` | Host bind mount (if configured) | ✅ Yes | opencode.json, skills, plus `oh-my-opencode-slim.json` on the OMOS variant |
+| `/home/developer/.config/opencode` | Named volume `devbox-opencode-config` | ✅ Yes | `opencode.jsonc`, skills, plus `oh-my-opencode-slim.json` on the OMOS variant |
 
-**opencode config** (`opencode.json`) is auto-generated from `OPENCODE_PROVIDER` on each start. It sets provider and model only — no MCP servers. To persist config changes and use custom settings, mount the config directory from the host (see Custom opencode config above).
+**opencode config** (`opencode.jsonc`) is auto-generated from `OPENCODE_PROVIDER` on each start. It sets provider and model only — no MCP servers. To persist config changes and use custom settings, use the named volume (default) or bind-mount from host (see Custom opencode config above).
 
 ## Source
 

README.md

@@ -49,9 +49,6 @@ Bind-mounted directories must exist on the host before starting the container. D
 ```bash
 # Required: workspace for your projects
 mkdir -p ~/projects
-
-# If mounting opencode config (recommended for persistent settings)
-mkdir -p ~/.config/opencode
 ```
 
 ### Connecting to the container
@@ -125,28 +122,34 @@ docker compose exec -u developer devbox aws --version
 | `OMOS_TMUX` | Enable tmux pane integration for OMOS | `false` |
 | `OMOS_SKILLS` | Install OMOS recommended skills on first run | `true` |
 | `OMOS_RESET` | Force regenerate OMOS config on next start | `false` |
+| `SKILLSET_CONTAINER_PATH` | Path to skillset repo inside container (for auto-deploy when not at /workspace/skillset) | Auto-detect |
 
 ### Custom opencode config
 
-For full control over opencode settings (MCP servers, custom models, and — on the OMOS variant — oh-my-opencode-slim agents), mount the entire config directory from the host:
+Opencode configuration is persisted automatically via the named volume `devbox-opencode-config`. This volume is mounted at `/home/developer/.config/opencode` by default — no host directory setup required. All changes to `opencode.jsonc`, skills, and (on the OMOS variant) `oh-my-opencode-slim.json` survive container recreation.
+
+When an existing `opencode.jsonc` is found in the volume, the `OPENCODE_PROVIDER` auto-config is skipped.
+
+**Alternative: host bind-mount** — if you specifically want to share config from the host (e.g. to version-control it or sync across machines), replace the named volume with a bind mount:
 
 ```yaml
 volumes:
   - ~/.config/opencode:/home/developer/.config/opencode
 ```
 
-This persists all configuration changes across container restarts, including `opencode.json`, skills, and (on the OMOS variant) `oh-my-opencode-slim.json`. When an existing `opencode.json` is found, the `OPENCODE_PROVIDER` auto-config is skipped.
+> **Portability note:** The mounted config runs inside a Linux container. Any absolute paths inside `opencode.jsonc` (for example, host-specific `plugin` entries like `file:///usr/local/lib/node_modules/...` or `file:///opt/homebrew/...`) will not resolve inside the container. Prefer bare package specifiers (e.g. `"oh-my-opencode-slim"`) that resolve via `node_modules` lookup, which works on both macOS and Linux hosts.
-
-> **Portability note:** The mounted config runs inside a Linux container. Any absolute paths inside `opencode.json` (for example, host-specific `plugin` entries like `file:///usr/local/lib/node_modules/...` or `file:///opt/homebrew/...`) will not resolve inside the container. Prefer bare package specifiers (e.g. `"oh-my-opencode-slim"`) that resolve via `node_modules` lookup, which works on both macOS and Linux hosts.
 
 ### Custom skills
 
-Mount agent skills from the host:
+Skills are deployed automatically from a skillset repo on container start. The entrypoint detects the skillset location in this order:
 
-```yaml
+1. `SKILLSET_CONTAINER_PATH` env var (explicit path to skillset repo inside container)
-volumes:
+2. `~/skillset` mount (if present)
-  - ~/.agents/skills:/home/developer/.agents/skills:ro
+3. `/workspace/skillset` fallback (if your workspace contains a `skillset/` directory)
-```
+
+When a skillset repo is detected, its skills are symlinked into `~/.agents/skills/` automatically. No manual configuration needed.
+
+> **Warning:** Do not bind-mount a host `~/.agents/skills` directory directly into the container. This conflicts with the symlink-based auto-deploy mechanism and causes broken skill references.
 
 ### Neovim configuration
 
@@ -294,9 +297,6 @@ cd ~/<signum>/opencode-devbox
 cp /path/to/opencode-devbox/docker-compose.shared.yml docker-compose.yml
 cp /path/to/opencode-devbox/.env.shared.example .env
 
-# Create per-user config directory
-mkdir -p ~/<signum>/.config/opencode
-
 # Edit .env — set SIGNUM only if you're in shared-account mode
 vim .env
 
@@ -308,7 +308,7 @@ docker compose exec -u developer devbox opencode
 Each user's container, config, and named volumes are fully isolated:
 - Container name: `devbox-<signum>` (or `devbox-$USER` in own-account mode)
 - Named volumes: prefixed with the project name (`devbox-<signum>_devbox-data`, etc.) — the Docker daemon is system-wide, so directory-name prefixing alone is NOT sufficient for isolation
-- Opencode config: `~/<signum>/.config/opencode/` (per-user settings, OMOS config, etc.)
+- Opencode config: persisted via per-user named volume (`devbox-<signum>_devbox-opencode-config`)
 
 See `docker-compose.shared.yml` and `.env.shared.example` for the full configuration.
 
@@ -468,7 +468,7 @@ Without the volume, palace data lives in the container's writable layer and is l
 
 ### MCP integration with opencode
 
-Add mempalace as an MCP server in your `opencode.json` (inside `~/.config/opencode/`):
+Add mempalace as an MCP server in your `opencode.jsonc` (inside `~/.config/opencode/`):
 
 ```json
 {
@@ -552,7 +552,7 @@ The image includes the [official Gitea MCP server](https://gitea.com/gitea/gitea
    GITEA_ACCESS_TOKEN=your_token_here
    ```
 
-3. Enable the gitea MCP server in your `opencode.json`:
+3. Enable the gitea MCP server in your `opencode.jsonc`:
    ```json
    {
      "mcp": {
@@ -570,6 +570,14 @@ The image includes the [official Gitea MCP server](https://gitea.com/gitea/gitea
 
 The server is installed but disabled by default — it requires authentication to be useful.
 
+## Context7 MCP server
+
+The image auto-registers a [Context7](https://context7.com) MCP server, which provides up-to-date library documentation and code examples to LLMs at query time. This is a remote MCP server at `mcp.context7.com/mcp` — no local binary is needed.
+
+- Auto-registered in the generated `opencode.jsonc` (no manual setup required)
+- Provides documentation for any programming library/framework on demand
+- Requires internet access — useless in air-gapped/offline environments
+
 ## Shell defaults
 
 The image ships a baked `.bash_aliases` and `.inputrc` with quality-of-life defaults. On first container start they are copied from `/etc/skel-devbox/` into `/home/developer/` **only if the target file does not already exist** — so host bind-mounts and any version you've customized inside the container are never overwritten on upgrade.
@@ -680,9 +688,9 @@ Container (Debian trixie)
 | `/home/developer/.rustup` | Named volume `devbox-rustup` (if configured) | ✅ Yes | Rust toolchains |
 | `/home/developer/.cargo` | Named volume `devbox-cargo` (if configured) | ✅ Yes | Cargo binaries, registry cache |
 | `/home/developer/.vscode-server` | Named volume `devbox-vscode` (if configured) | ✅ Yes | VS Code server and extensions |
-| `/home/developer/.config/opencode` | Host bind mount (if configured) | ✅ Yes | opencode.json, skills, plus `oh-my-opencode-slim.json` on the OMOS variant |
+| `/home/developer/.config/opencode` | Named volume `devbox-opencode-config` | ✅ Yes | `opencode.jsonc`, skills, plus `oh-my-opencode-slim.json` on the OMOS variant |
 
-**opencode config** (`opencode.json`) is auto-generated from `OPENCODE_PROVIDER` on each start. It sets provider and model only — no MCP servers. To persist config changes and use custom settings, mount the config directory from the host (see Custom opencode config above).
+**opencode config** (`opencode.jsonc`) is auto-generated from `OPENCODE_PROVIDER` on each start. It sets provider and model only — no MCP servers. To persist config changes and use custom settings, use the named volume (default) or bind-mount from host (see Custom opencode config above).
 
 ## License
 

scripts/generate-dockerhub-md.py

@@ -66,7 +66,8 @@ SECTION_RULES: dict[str, str] = {
     "AWS Bedrock Authentication": "keep",
     "MemPalace — persistent AI memory": "keep",
     "Gitea MCP server": "keep",
-    "Shell defaults": "keep",
+    "Context7 MCP server": "drop",
+    "Shell defaults": "drop",                   # detail, full README covers it
     "Secret Scanning": "drop",                  # dev-only — gitleaks is for committers
     "Architecture": "keep",
     "License": "replace",                       # point at source repo instead