brickpit

A ready-to-go, AI assistant integrated, devcontainer for doing Databricks development in VS Code.

What this gives you

• Databricks CLI + VS Code extension — OAuth login works out of the box. The extension's browser callback normally breaks inside a devcontainer (VS Code's port auto-forwarding intercepts the one-shot OAuth callback); this repo's devcontainer.json works around that.
• A JDK, for a local PySpark/Delta JVM for fully local unit testing (py4j needs a real JVM even though everything else in this environment is pure Python) — this is what lets a bind-mounted sibling repo like pyspark-tdd-scaffold run its test suite entirely locally.
• dbt (the Fusion CLI), installed automatically — it isn't available via pip/apt, so it's pulled from its own installer on container creation.
• Claude Code, wired up with Databricks' official skills (databricks-pipelines, databricks-dabs, databricks-unity-catalog, etc.) so it already knows Databricks conventions rather than guessing.
• Pi, a second, more minimal coding agent harness — installed alongside Claude Code, not in place of it. Run pi, then /login once to authenticate (Claude Pro/Max, ChatGPT Plus/Pro, GitHub Copilot, or an API-key provider); credentials persist across rebuilds the same way Claude Code's do (see below).
• Persistence across rebuilds — Claude Code's session history, Pi's settings/sessions/credentials, and your git identity (user.name/user.email) all live in named Docker volumes, so rebuilding the container doesn't reset any of them.
• Optional air-gapped development — Pi can be optionally configured to use a local LLM served by your Mac. (In this example we are using LM Studio serving qwen3.6-35b on an M1 Max). Point Pi at host.docker.internal:1234 and no data leaves your machine.

All of this is set up by .devcontainer/postCreateScripts/*.sh, run in order the first time the container starts — see .devcontainer/postCreateScripts/README.md for what each step does.

Multi-repo workspace

brickpit is meant to be the environment, not necessarily where your project code lives. brickpit.code-workspace opens this repo side-by-side with sibling repos — e.g. pyspark-tdd-scaffold, bind-mounted in via devcontainer.json — so a project repo doesn't need its own devcontainer; it just needs to exist as a sibling folder on your host machine (~/code/brickpit + ~/code/pyspark-tdd-scaffold) and gets the Linux runtime, JDK, and tooling from here for free.

~/code/                              (host)
├── brickpit/                        ← this repo; devcontainer lives here
│   └── brickpit.code-workspace      ← opens both folders together
└── pyspark-tdd-scaffold/            ← sibling project repo, no devcontainer of its own

                    │  devcontainer.json bind-mounts the sibling in
                    ▼

/workspaces/                         (inside the container)
├── brickpit/                        ← this repo
└── pyspark-tdd-scaffold/            ← bind-mounted from ~/code/pyspark-tdd-scaffold

Getting started

1. Clone this repo.
2. (Optional) Clone any sibling project repos you want alongside it — e.g. pyspark-tdd-scaffold — as siblings on the host (~/code/brickpit, ~/code/pyspark-tdd-scaffold).
3. Open brickpit.code-workspace in VS Code and reopen in the devcontainer when prompted. First build runs the postCreateScripts automatically.
4. Sign in via the Databricks extension (OAuth) or databricks auth login.

Layout

• notebooks/ — scratch Databricks notebooks (# Databricks notebook source cell markers), for sanity-checking things like Databricks Connect against a real workspace.
• Workspace/ — scratch space for syncing against the connected Databricks workspace.
• .claude/skills/ — Databricks' official Claude Code skills, pulled in by postCreateScripts/04-install-claude-skills.sh; gitignored so each container gets a fresh copy rather than committing vendored skill files.

Corporate networks

The Dockerfile and postCreateScripts pull tools straight from public sources over HTTPS (uv, the Databricks CLI, dbt, pip/apt packages). If you're on a corporate network with TLS-inspecting proxies, those requests will fail cert validation until your org's inspection CA certificate(s) are trusted inside the image — add a step to the Docker build sequence (e.g. COPY the cert(s) into /usr/local/share/ca-certificates/ and run update-ca-certificates in Dockerfile) before building on such a network.

Separately, you may also want to point these installs at an internal artifactory/mirror instead of the public sources (e.g. a PyPI/apt/npm proxy) rather than reaching out to the public internet directly — that means adjusting the relevant pip/uv/apt index URLs in Dockerfile and the postCreateScripts install commands to your org's mirror.