This repository contains my configuration files. They are
Manual steps to install dotfiles on a new system
- Run
install-setup.sh - Download and install nerd font patched Fira Code font from https://github.com/ryanoasis/nerd-fonts/releases
# Leaving a machine
brew bundle dump
# Fresh installation
brew bundle# Create the symbolic links using GNU stow.
$ git clone https://github.com/ChristianMoesl/dotfiles
$ cd dotfiles
$ stow -t ~ ..pi/agent/mcp.json configures the official Blender Lab MCP server, not
Ahujasid's separate Blender MCP project. The two bridges use different protocols,
even though both default to port 9876. Install the server from its official source,
not an unrelated package with the same blender-mcp name on PyPI.
The server runs in a dedicated WSL virtual environment, launched by Pi over stdio.
It connects to the Windows Blender extension at 127.0.0.1:9876 using WSL mirrored
networking. No HTTP server, Windows firewall changes, or Blender installation in
WSL are needed for this setup. Keep the bridge on loopback: it can execute Python
inside Blender and is not an authenticated network service.
Install the server once, using a Python installation with working venv/pip
support (the tested WSL installation uses Homebrew Python 3.14):
git clone --depth 1 --branch v1.0.3 \
https://projects.blender.org/lab/blender_mcp.git \
"$HOME/.local/share/blender-lab-mcp"
python3 -m venv "$HOME/.local/share/blender-lab-mcp/.venv"
"$HOME/.local/share/blender-lab-mcp/.venv/bin/python" -m pip install \
'mcp[cli]==1.30.0' "$HOME/.local/share/blender-lab-mcp/mcp"
"$HOME/.local/share/blender-lab-mcp/.venv/bin/python" -m pip checkVersion v1.0.3 resolves to commit 2cea8d566dde07fbac28a61d698909d69724e853.
The source checkout and virtual environment stay outside this dotfiles repository.
Do not update them implicitly at Pi startup. Match server and extension versions
when upgrading, then repeat the connection tests.
Stow links .pi/agent/mcp.json into ~/.pi/agent/mcp.json. If not using Stow, link
only this file from the root of this repository, provided the destination does
not already exist:
mkdir -p "$HOME/.pi/agent"
ln -s "$PWD/.pi/agent/mcp.json" "$HOME/.pi/agent/mcp.json"If a configuration already exists, merge the blender entry rather than replacing
other servers or credentials. The shared configuration contains no credentials;
keep future authenticated server entries machine-local rather than committing them.
In Windows Blender, enable the Blender Lab MCP extension and start its bridge. Enable Bonsai separately and save preferences. Only one Blender instance can own this bridge port; multiple instances can connect the agent to the wrong file.
Run pi mcp list to check MCP initialization and tool discovery. This does not
verify that Blender is reachable: also ask Pi to read the current scene summary and
confirm Bonsai/IfcOpenShell are loaded. Run /reload in an existing Pi session,
then /mcp to inspect the connection. No separate always-running MCP daemon is
required; Pi manages the server process.
Four common tools are directly exposed; the remaining interactive tools are
available through codemode/tool search. *_for_cli tools are hidden because they
expect a Blender executable and filesystem local to the MCP server. This setup
uses Windows Blender instead. Code executed inside Blender must use Windows paths
and IFC-aware APIs for Bonsai elements, not arbitrary mesh edits. Python source
files can remain in WSL and be sent through MCP or staged to Windows when needed.
To disable Blender in other projects or on machines without the server, use
/mcp or a trusted project .pi/mcp.json override:
{"mcpServers": {"blender": {"enabled": false}}}.pi/agent/agents/ defines seven global roles for @gotgenes/pi-subagents.
Stow links the directory into ~/.pi/agent/agents/.
The setup is cost-conscious rather than a mandatory multi-agent pipeline:
Sol supervises, Haiku handles routine delegated work, Sol specialists handle
ambiguity or high risk, and Opus handles visual-design deliverables. The parent
startup default is github-copilot/gpt-6.1-sol with high thinking.
All models below use the github-copilot/ provider prefix.
| Agent | Model | Thinking | Turns | Use |
|---|---|---|---|---|
Explore |
claude-haiku-5.5 |
low | 16 | Bounded discovery with file/line evidence; no edits |
worker-fast |
claude-haiku-5.5 |
low | 20 | Default routine implementer, including focused tests |
Verify |
claude-haiku-5.5 |
low | 16 | Separate checks when useful; no source edits or fixes |
Plan |
gpt-6.1-sol |
high | 24 | Material design decisions; no edits |
general-purpose |
gpt-6.1-sol |
high | 40 | Difficult debugging, high-risk work, or Haiku escalation |
Review |
gpt-6.1-sol |
high | 24 | Independent, evidence-backed review; no edits or submissions |
Visual |
claude-opus-5.5 |
high | 32 | HTML presentations, GUI concepts, and visual aids |
Keep the automatic routing policy in the personal ~/.pi/agent/AGENTS.md
(managed separately from this repository). Handle tiny tasks directly, default
routine delegation to Haiku, and use planning, separate verification, and review
only when they add value. Escalate unresolved technical blockers with the evidence
already collected, not repeated blind retries. Missing user decisions or
permissions require clarification, not a stronger model. Do not assign overlapping
edits or run checks while another worker changes the same files.
All roles default to fresh context and lock only their model. Supply a compact task brief with scope, constraints, acceptance criteria, and relevant evidence. Thinking levels, turn ceilings, context inheritance, and foreground/background mode remain caller-selectable. Turn ceilings are not hard token or cost budgets. To escalate to another model, dispatch the appropriate role; overriding a locked model in a tool call is ignored.
All roles allow codemode for batching independent tool calls. Workers can edit;
Explore, Plan, and Review retain Bash for Git inspection, so their read-only
behavior is instruction-based, not an enforced shell sandbox. Verify can run
tests/builds that generate artifacts and reports those changes without fixing or
cleaning them. Visual uses the existing playwright-cli skill for preview,
reports verification gaps, and follows the personal screenshot-location policy.
After changing definitions or personal instructions, run /reload in Pi.
The parent thinking default applies at startup; use /thinking to change the
current session (resumed sessions retain their recorded selection). To change a
role's model, edit its model: frontmatter. The model must be available to Pi;
the parent's enabledModels cycling list does not restrict these subagents.
Project-local .pi/agents/<name>.md definitions take precedence over the global
files. Agent files are complete definitions, not partial patches.
The shared .gitconfig uses credential.helper = manager, not an OS-specific
installation path. Git resolves git-credential-manager through its executable
search path. Install Git Credential Manager (GCM) on each machine and verify
it is discoverable from the environment running Git (including GUI clients):
git credential-manager --versionThis works on Linux, macOS, and Windows without changing the shared config.
WSL can use a Linux GCM installation, or a machine-local path override pointing
to Windows GCM. GitHub and Gist retain their more-specific gh helpers; install
GitHub CLI and authenticate with gh auth login for those hosts.
~/.gitconfig.local is included last for installation-specific paths or
credential-store settings; see .gitconfig.local.example. A local helper
replacement needs an empty helper = followed by the desired helper. This
clears all matching inherited helpers, including GitHub's gh helper. Remove
redundant local helper entries to retain the shared per-host choices.
GCM uses native credential stores on macOS and Windows. On Linux, choose and
configure a secure backend such as secretservice (desktop keyring) or gpg
(pass), and set credential.credentialStore in the local file. Do not put
credentials or machine-specific store settings in the shared config.
Avoid running git credential-manager configure against the shared config:
it can append an absolute helper path after the local include. These dotfiles
already configure the helper; keep machine-specific changes in the local file.
The shared .gitconfig defaults to Christian Mösl, christian.git@moesl.net,
and the personal Ed25519 signing key, using 1Password's WSL signing program.
Commit signing is enabled. This is SSH signing (gpg.format = ssh), not OpenPGP
signing.
~/.gitconfig.local is included last for machine-specific overrides and is not
committed. See .gitconfig.local.example for platform-specific 1Password signer
paths, plus optional identity and credential-helper overrides. Copy the example
only if the local file does not exist; otherwise merge the settings you need.
On non-WSL machines, override the signing program before committing (or
explicitly disable signing if no signing agent is configured). There is no
automatic OS detection.
Enable the SSH agent in the Bitwarden desktop app and make both the personal and Gofore SSH keys available to it. Private keys stay in Bitwarden; Git stores only their public keys and asks the agent to sign through OpenSSH.
On this Mac, merge the following into ~/.gitconfig.local:
[user]
email = christian.moesl@gofore.com
signingkey = ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPklDU6sPmpBLqArC9GWeYktYfmGNGW6+9swIyRu1YBG
[gpg "ssh"]
program = /usr/bin/ssh-keygenThe name, gpg.format = ssh, and commit.gpgsign = true remain inherited from
the shared config.
Add the socket setting to the machine-local ~/.zshenv.local, not to shared
shell configuration. The shared .zshenv loads this file for both interactive
and non-interactive zsh shells. Remove any old SSH_AUTH_SOCK export from
~/.zshrc.local so it cannot override this guard:
# Use Bitwarden locally without overriding SSH-forwarded agents.
if [[ -z "$SSH_CONNECTION" && -S "$HOME/.bitwarden-ssh-agent.sock" ]]; then
export SSH_AUTH_SOCK="$HOME/.bitwarden-ssh-agent.sock"
fiThe guard preserves the inherited agent in SSH sessions and when the Bitwarden
socket is absent. This is the socket for the Bitwarden desktop app installed
from the .dmg. For the App Store version, use
$HOME/Library/Containers/com.bitwarden.desktop/Data/.bitwarden-ssh-agent.sock
in both places instead.
Open a new terminal or run source ~/.zshenv.local in the existing one, then
verify agent access:
ssh-add -lRestart Pi from that terminal so it inherits the new socket. Bash subprocesses
do not read .zshenv; they inherit the environment of the process launching
them. An already-running Pi process does not pick up changes to its parent
shell's environment, and GUI launchers may need separate environment setup.
pi-sbx, radar, and dotfiles use christian.git@moesl.net and the personal
signing key. Set these in each repository's local Git config, which takes
precedence over ~/.gitconfig.local:
personal_key=$(git config --file "$HOME/.gitconfig" --get user.signingkey)
for repo in pi-sbx radar dotfiles; do
git -C "$HOME/Workspace/$repo" config --local user.email christian.git@moesl.net
git -C "$HOME/Workspace/$repo" config --local user.signingkey "$personal_key"
doneThe signing program is still inherited from the machine-local config. Other
repositories should have no local identity/signing overrides, so they inherit
the Gofore identity and key on this Mac. Linked worktrees also read the shared
repository-local config, including its identity/signing overrides. A worktree
can override those values in its own config.worktree when
extensions.worktreeConfig is enabled.
Inspect configuration sources from inside a repository:
git config --show-origin --show-scope --get-regexp \
'^(user\.(name|email|signingkey)|gpg\.format|gpg\.ssh\.program|commit\.gpgsign)$'The output includes inherited and overridden entries, not just final values.
Use git config --get user.email and git config --get user.signingkey to
check the effective identity. Remove unwanted local overrides individually
with git config --local --unset-all <key>; worktree-specific overrides need
--worktree instead.
For GitHub's Verified badge, register each public key as an SSH signing
key and verify the email used by its commits. An allowedSignersFile is
needed for local SSH-signature verification, not for creating signatures.
SBX configuration is separate from the host Git and shell setup; these dotfiles are not loaded inside SBX. To forward Bitwarden explicitly from the Mac:
sbx settings set ssh.agentForwardingEnabled true
sbx settings set ssh.agentSocketPath "$HOME/.bitwarden-ssh-agent.sock"
sbx daemon restartThese are global SBX settings, affecting existing sandboxes too. Restarting the daemon reconnects existing agent forwarders, so choose a suitable time for active sandbox sessions. No private-key export or host socket bind-mount is needed. Forwarding allows sandbox processes to request signing/authentication from the agent; retain Bitwarden's approval protections.
The sandbox image needs OpenSSH client tools and socat. Inside the sandbox,
check the forwarded agent and configure Git separately:
command -v ssh-keygen ssh-add socat
ssh-add -l
git config --global user.name "Christian Mösl"
git config --global user.email christian.moesl@gofore.com
git config --global user.signingkey 'ssh-ed25519 REPLACE_WITH_YOUR_PUBLIC_KEY'
git config --global gpg.format ssh
git config --global gpg.ssh.program ssh-keygen
git config --global commit.gpgsign trueReplace the placeholder with the intended public key: the Gofore key above for
work repositories, or the personal key for personal repositories. Apply the
personal repository overrides inside the relevant sandbox repositories too,
using their sandbox paths. Do not set the Mac's socket path inside Linux;
SBX supplies the sandbox-local SSH_AUTH_SOCK.
- Map cap lock key to ESC in system settings
- Enable CTRL+number shortcuts for Missing Control in system settings (keyboard)
- Disable CTRL+Space shortcut for "previous input source" in system settings (keyboard)
- Enable "reduce motion" in accessibility settings
- Disable "Automatically rearrange Spaces ..." in Desktop & Dock
- Configure OpenAI key in ~/.config/nvim/.chat-gpt
MIT.