Pioneer creates a default workspace automatically on first launch. You can keep using it, or create additional workspaces from the workspace selector at the top of the main thread sidebar.
The active workspace is where your threads, provider keys, MCP servers, skills, tasks, settings, and artifacts come together for the gateway you are connected to. Switching workspaces changes the thread tree and the workspace-scoped configuration the app shows.
Manage Workspaces
Use the workspace selector in the left thread sidebar to:
- switch to another workspace;
- create a new workspace;
- rename an existing workspace.
New threads are created in the active workspace. Provider setup, MCP installation, skill availability, tasks, and artifacts are also resolved through the active workspace.
Use Workspaces For Project Separation
Use separate workspaces when the work should stay separate but can share the same gateway machine and execution environment. Common examples are clients, projects, experiments, or personal contexts that should have different threads, provider keys, MCP servers, skills, and tasks.
Workspaces are not security sandboxes. They organize gateway-owned state, but tools still execute as the gateway OS user and can reach whatever that gateway process can reach.
Use Gateways For Environment Separation
Use a separate gateway when the machine, files, accounts, network access, task schedules, or security boundary should be different. A work gateway can stay close to work repositories and internal tools. A home gateway can run on a personal server. A sandbox gateway can exist only for testing tools and skills.
The desktop app can connect to all of them, but gateways do not share state. Each gateway has its own database, keystore, workspaces, provider settings, skills, MCP servers, tasks, and execution environment.
Use Threads For Context
Inside each workspace, use threads to keep work understandable.
Use one thread for one goal. Start a new thread when the topic changes, when you move from research to edits, or when you want a clean context. Name threads clearly so you can find them later.
For example, Research MCP server options is more useful than Notes, and Fix gateway status on macOS is more useful than Bug.
A workspace is not a sandbox. Tool runs still execute as the gateway OS user.
