Skip to main content
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-..."
  }
}
FieldDescription
nameDisplay name for the server
typeMust be stdio
commandThe executable to run
argsCommand-line arguments (array of strings)
envEnvironment 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"
}
FieldDescription
nameDisplay name for the server
typeMust be http
urlThe 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:
FieldDescription
NameThe slash command name (e.g., deploy)
DescriptionWhat the skill does — shown to the agent
ContentThe 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.
OptionDescription
DisabledTasks never auto-sleep
1 minuteFor testing purposes
5 minutesAggressive — saves compute but may interrupt work
10 minutesBalanced
15 minutesDefault
30 minutesRelaxed
1 hourLong-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:
ModeDescription
DefaultStandard permission handling
Plan ModePlan changes before executing
Accept EditsAuto-approve file edits only
Bypass PermissionsAuto-approve all actions
Codex:
ModeDescription
DefaultUse Codex CLI defaults
UntrustedOnly trusted commands run without approval
On RequestCodex decides when to request approval
Never AskNever ask for approval (sandbox still applies)
Danger Full AccessNo 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:
LevelDescription
DefaultUse Codex defaults
LowMinimal reasoning — fastest
MediumBalanced
HighThorough reasoning
XHighMaximum 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):
ProviderRuntimeDescription
ClaudeClaude Code CLIAnthropic’s native coding agent
CodexCodex CLIOpenAI’s native coding agent
CCRClaude Code RunnerClaude 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.