Client Workspace Setup

If you work with clients, you need isolation -- one client's data should never leak into another client's workspace. A client workspace enforces this boundary. It is a dedicated Claude Code environment for a single engagement, with its own configuration, its own file boundaries, and its own credentials. When you open it, Claude knows exactly which client it is working for. When you close it and open a different client workspace, that context does not carry over.

This is not just good practice -- for many businesses it is a compliance requirement. GDPR and other data protection frameworks require that personal data belonging to one client is not commingled with another's, and that access is limited to what is necessary for the engagement.

Session banner -- mandatory

Client workspaces must display an identity banner at the start of every session. This makes the active client context visible before any work begins, preventing accidental cross-contamination between clients or between client and personal work.

# CLAUDE.md -- Acme Construction Ltd

## CLIENT WORKSPACE -- ACME CONSTRUCTION LTD
Display this banner at the start of every /day session and whenever
the workspace context is ambiguous.

## Workspace Identity
- Name: Acme Construction Ltd
- Type: client
- GitHub: acme-org/acme-biz-os

Scoping access

A client workspace should be tightly scoped:

• File system access -- limit to the workspace root. Do not grant access to ~/Documents or other directories containing your personal or other-client work. Explicitly state the accessible paths in CLAUDE.md.
• MCP servers -- register only servers relevant to this engagement. A client workspace for a property management firm does not need your personal calendar or email server.
• Git remote validation -- add a pre-push check comparing state.json workspace identity against git remote get-url origin. Mismatch = abort push.

Credential handling

Never store client API credentials in the repository. The pattern:

1. Define server configurations in .mcp.json using environment variable references: "env": {"API_KEY": "${CLIENT_API_KEY}"}
2. Document required environment variables in SETUP.md
3. Each person working on the engagement sets the variables in their local .env or shell profile
4. The .env file is listed in .gitignore -- a file that tells version control to ignore certain files so they never leave your machine. Client credentials, sensitive documents, and personal config all belong here.

OAuth integrations

Some services -- Google Drive, Microsoft 365, project management platforms -- use OAuth for access. OAuth is a secure way to grant Claude access to a service without sharing your password. You approve the connection once through a browser login; from that point on, the service recognises Claude as an authorised application and handles authentication automatically. OAuth tokens are stored locally (in ~/.claude.json or equivalent) and should never be committed to the repository.

Privacy and compliance

Beyond the workspace boundary, consider what data Claude actually processes during a session:

• Data minimisation -- only give Claude access to the client files relevant to the current task. Avoid loading entire client databases or document archives into a session when only a subset is needed.
• Data residency -- Claude processes data via Anthropic's servers. If your client has contractual restrictions on where their data can be processed, verify Anthropic's data processing agreement covers the relevant regions before using Claude Code for that engagement.
• Retention -- conversation history is stored by Anthropic. For sensitive engagements, review what appears in conversation vs what remains on disk only.
• Client data on disk -- files you read into sessions may leave traces in conversation history. The workspace boundary controls what Claude can access, but does not control what Anthropic retains from conversations.

Setting up a new client workspace from scratch

1. Create a new directory for the client: e.g. ~/Developer/acme-construction/
2. Initialise a git repository and connect it to a private remote -- one per client, never shared
3. Create .claude/CLAUDE.md with the client identity, accessible folders limited to this workspace, and any client-specific conventions (their preferred terminology, document formats, communication style)
4. Create .mcp.json with any integrations specific to this engagement, using environment variable placeholders for credentials
5. Create .gitignore and add .env, *.db, any client documents that should not be version-controlled
6. Add a SETUP.md listing the environment variables required, where to obtain credentials, and how to verify the workspace is operational
7. Run /day to confirm the session banner displays correctly and the workspace reads as the right client

Reproducibility

A client workspace should be reproducible from scratch without your involvement. The repository, together with SETUP.md, should be sufficient for another team member (or you, on a new machine) to get fully operational. Document required MCP server dependencies, external accounts, OAuth apps, and how to run the first-session validation.