Workspace configuration controls the coding environment that every task in your workspace runs in. These settings are managed in Settings → Configuration → Configurations and apply across all AI providers unless noted otherwise.
Each setting can be configured at the workspace defaults level (shared with all members) or the user defaults level (personal). See Settings Overview for how inheritance works.
MCP Servers
MCP (Model Context Protocol) servers extend your AI agent’s capabilities by giving it access to external tools and data sources. Whim supports two transport types:
Stdio Servers
Stdio servers run as a local process inside the task container. The agent communicates with the server over standard input/output.
{
"name": "my-mcp-server",
"type": "stdio",
"command": "npx",
"args": ["-y", "@example/mcp-server"],
"env": {
"API_KEY": "sk-..."
}
}
| Field | Description |
|---|
name | Display name for the server |
type | Must be stdio |
command | The executable to run |
args | Command-line arguments (array of strings) |
env | Environment variables passed to the server process |
HTTP Servers
HTTP (streamable) servers run externally and are accessed over HTTPS. Use these for shared services or servers that need to persist across tasks.
{
"name": "remote-server",
"type": "http",
"url": "https://mcp.example.com/sse"
}
| Field | Description |
|---|
name | Display name for the server |
type | Must be http |
url | The HTTP endpoint URL |
MCP Server Inheritance
MCP servers use merge semantics. Servers defined at the workspace level are combined with servers from your user defaults. If both levels define a server with the same name, you can control which takes priority using source ordering.
Skills
Skills are custom capabilities that extend what your AI agent can do. They act as slash commands that the agent can invoke during a task — for example, /deploy, /run-tests, or /lint.
Skills can be defined at both workspace and user levels. Like MCP servers, they use merge semantics, so workspace skills and personal skills are combined.
Use the skills editor in the settings UI to add, edit, or remove skills. Each skill entry includes:
| Field | Description |
|---|
| Name | The slash command name (e.g., deploy) |
| Description | What the skill does — shown to the agent |
| Content | The prompt or instructions the agent follows when the skill is invoked |
Environment Variables
Environment variables are injected into every task container in the workspace. They are commonly used for API keys, database URLs, and service credentials.
DATABASE_URL=postgresql://localhost:5432/mydb
OPENAI_API_KEY=sk-...
DEBUG=true
Key features
- Secret detection — Whim automatically detects keys that look like secrets (containing
KEY, SECRET, TOKEN, PASSWORD, etc.) and masks their values in the UI.
- Merge semantics — environment variables from workspace defaults and user defaults are merged. If the same key exists at both levels, source ordering determines which value wins.
- Source ordering — you can drag to reorder env sources, controlling whether workspace defaults or user defaults take priority.
Env files
Environment variables are managed as env files — named groups of key-value pairs. You can create multiple env files to organize variables by concern (e.g., api-keys, database, feature-flags).
Plugins
Plugins add pre-built integrations from the Claude marketplace to your workspace. They are toggled on or off per workspace and per provider.
Plugins are available for Claude and CCR (OpenRouter) providers. They are not currently supported for Codex.
Plugins use merge semantics — plugins enabled at the workspace level are combined with plugins from your user defaults.
Scripts
Whim supports three types of scripts that run at different points in the container lifecycle:
Instructions (CLAUDE.md)
Custom instructions written in Markdown that are injected into the agent’s system prompt. Use these to set coding standards, define project conventions, or provide context about your codebase.
# Project Conventions
- Use TypeScript strict mode
- Write tests for all new functions
- Follow the existing naming conventions
Instructions from workspace defaults and user defaults are concatenated — both sets of instructions are included, with workspace instructions appearing first.
Initialization Script (init.sh)
A bash script that runs once when the task container starts, before the AI agent begins work. Use it for setup tasks like installing dependencies or configuring tools.
# Install project dependencies
npm install
# Set up database
createdb myproject_dev
Init scripts from multiple levels are concatenated and run in sequence.
Shell Configuration (.bashrc)
Shell configuration loaded into each terminal session. Use it for aliases, PATH modifications, or shell customizations.
# Custom aliases
alias ll='ls -la'
alias gs='git status'
# Add project bin to PATH
export PATH="$PATH:./node_modules/.bin"
Like init scripts, shell configurations from multiple levels are concatenated.
Auto-Sleep
Auto-sleep automatically suspends idle task containers to conserve compute units. When a task has had no terminal activity for the configured duration, Whim puts it to sleep. You can resume a sleeping task at any time.
| Option | Description |
|---|
| Disabled | Tasks never auto-sleep |
| 1 minute | For testing purposes |
| 5 minutes | Aggressive — saves compute but may interrupt work |
| 10 minutes | Balanced |
| 15 minutes | Default |
| 30 minutes | Relaxed |
| 1 hour | Long-running tasks |
Auto-sleep can be set at both workspace and user levels. The most specific value wins.
Provider Defaults
Provider settings are configured per AI provider (Claude, Codex, CCR) in Settings → Configuration → Providers. Switch between provider tabs to configure each one independently.
Model
Select the default AI model for tasks in this workspace. The available models depend on the selected provider:
- Claude — Claude model variants (e.g., Sonnet, Opus)
- Codex — GPT model variants
- CCR (OpenRouter) — models available through OpenRouter
Permission Mode
Controls how the AI agent requests permission before taking actions. Options vary by provider:
Claude / CCR:
| Mode | Description |
|---|
| Default | Standard permission handling |
| Plan Mode | Plan changes before executing |
| Accept Edits | Auto-approve file edits only |
| Bypass Permissions | Auto-approve all actions |
Codex:
| Mode | Description |
|---|
| Default | Use Codex CLI defaults |
| Untrusted | Only trusted commands run without approval |
| On Request | Codex decides when to request approval |
| Never Ask | Never ask for approval (sandbox still applies) |
| Danger Full Access | No approvals and no sandbox protections |
Bypass Permissions (Claude) and Danger Full Access (Codex) disable safety checks. Use these modes only when you understand the risks.
Fast Mode
When available, fast mode prioritizes output speed over reasoning depth. This is useful for straightforward tasks where speed matters more than careful deliberation. Fast mode availability depends on the selected model.
Reasoning Effort (Codex only)
Controls the depth of reasoning for Codex tasks:
| Level | Description |
|---|
| Default | Use Codex defaults |
| Low | Minimal reasoning — fastest |
| Medium | Balanced |
| High | Thorough reasoning |
| XHigh | Maximum reasoning depth |
Experimental Features (Codex only)
Toggle experimental Codex features. Changes are saved to the Codex config.toml file.
AI Provider Selection
Your default AI provider determines which coding runtime runs inside each task container. This is a user-level setting (each team member chooses their own provider):
| Provider | Runtime | Description |
|---|
| Claude | Claude Code CLI | Anthropic’s native coding agent |
| Codex | Codex CLI | OpenAI’s native coding agent |
| CCR | Claude Code Runner | Claude models via OpenRouter API keys |
Switch providers in Settings → Configuration → Providers using the provider cards at the top of the page, or run the Setup Wizard from the settings sidebar.