Claude Code can work with more than the files in your current repository. Through the Model Context Protocol (MCP), it can also search, read, and update a shared knowledge workspace.
For teams, this changes an important part of the workflow: product decisions, research notes, launch plans, and operating tables no longer have to be copied into every prompt. Claude Code can retrieve the current source of truth from the workspace and write reviewed outputs back to the same place.
The short answer
To connect Claude Code to a shared workspace:
Create a workspace-scoped MCP connection in your knowledge system.
Add its remote HTTP endpoint to Claude Code.
Authenticate without committing credentials to the repository.
Confirm that Claude Code can list, search, and read workspace resources.
Grant write access only when the workflow requires it.
In Dokki, an MCP connection is limited to one workspace. That boundary is useful: an agent connected to the GTM workspace does not automatically gain access to HR, finance, or another customer workspace.
Why use a shared workspace instead of repository files?
Repository files are the right source of truth for code, configuration, and versioned technical documentation. They are less suitable for information that belongs to multiple functions or changes outside the code review cycle.
A shared workspace is a better home for:
customer and competitor research;
positioning and messaging decisions;
campaign calendars and launch checklists;
product briefs and meeting decisions;
structured tables maintained by non-engineering teammates;
reusable context needed by several agents.
The strongest setup uses both systems. Claude Code reads implementation truth from the repository and business context from the shared workspace. It then links the two in a reviewable output.
Prerequisites
Before connecting anything, confirm that you have:
a recent Claude Code installation;
access to the target workspace;
permission to create a personal key or managed connector;
a clear decision about read-only versus read-and-write access;
a small test document that contains no sensitive data.
Run claude mcp from the terminal to inspect Claude Code's MCP configuration commands. Anthropic documents local, project, and user scopes, as well as remote HTTP transports. For a cloud workspace, remote HTTP is normally the appropriate transport.
Step 1: choose the correct connection model
Dokki supports two practical connection patterns.
Personal connection
A personal connection is the fastest route for an individual operator. Generate the connection details in the workspace settings and add them to Claude Code. Use this for your own machine, experimentation, or a short proof of concept.
Managed connector
A managed connector is better for a team or long-running agent. It is named, workspace-scoped, auditable, and independently revocable. Use it when access must survive employee changes, be rotated deliberately, or be separated by workflow.
Do not reuse one broad credential for every agent. Create separate connections for different trust boundaries, such as research-readonly, editorial-writer, and release-operator.
Step 2: decide the Claude Code scope
Claude Code supports three MCP configuration scopes:
local scope: private to you and available only in the current project;
project scope: stored in the repository-level .mcp.json file and shared with the team;
user scope: private to you and available across projects on your machine.
For a shared workspace, the configuration and the secret should be treated separately.
A project-scoped configuration can standardize the server name and endpoint for the team, but credentials should not be committed to version control. If the generated connection includes a private token or unique URL, prefer local or user scope unless your credential system injects the secret safely.
Claude Code asks for approval before it uses project-scoped MCP servers discovered in .mcp.json. That approval step helps prevent a newly cloned repository from silently activating an untrusted server.
Step 3: add the remote MCP server
Use the exact command generated by the workspace connection screen. A generic remote HTTP command follows this shape:
claude mcp add --transport http WORKSPACE_NAME MCP_ENDPOINT
If authentication is passed as a header, use Claude Code's supported header option or the exact command provided by the service. Never paste a real token into documentation, a shell-history screenshot, an issue, or a committed .mcp.json file.
After adding the server, inspect the configured servers:
claude mcp list
Then start Claude Code and open the MCP menu:
/mcp
Complete any browser authentication flow and confirm that the server reports a healthy connection.
Step 4: test the connection in read-only mode
Start with a narrow verification sequence. Ask Claude Code to:
List the workspaces or resources it can access.
Search for the title of the harmless test document.
Read that document and summarize one specific section.
Report the workspace name and resource URL it used.
A good test prompt is:
Search the connected workspace for the onboarding test document. Summarize its decision section in three bullets, and include the source resource title and URL. Do not edit anything.
This checks discovery, semantic search, document reading, and source attribution without creating side effects.
Step 5: test a controlled write
If the workflow needs write access, create a disposable document or table row. Do not begin by editing a production brief.
Example:
Create a document named MCP Connection Test in the Sandbox folder. Add today's date, the connected server name, and a note that this document can be deleted. Return the resource URL.
Verify the result in the workspace UI. Check that the document landed in the correct workspace and folder, that the author or agent activity is visible, and that no other resource changed.
A practical team workflow
Once the connection is verified, Claude Code can bridge software work and shared organizational context.
Before implementation
Ask it to retrieve the approved product brief, relevant customer evidence, and the current acceptance criteria. Require source links so reviewers can trace each claim.
During implementation
Keep code changes in the repository. Use the workspace for decisions that need broader visibility, such as a tradeoff log, launch risk, or documentation gap.
After implementation
Have Claude Code write a reviewable release note or implementation summary back to the workspace. It should link the pull request, list behavior changes, and call out unresolved decisions.
This produces a closed loop:
shared context to implementation to reviewed output to shared memory.
Recommended permissions
Apply least privilege by workflow rather than by convenience.
A connection that can search documents does not automatically need permission to delete resources, share them publicly, or manage members.
Security checklist
Before rolling the connection out to a team, verify the following:
The credential is scoped to one workspace.
Secrets are excluded from Git and shell recordings.
Each automation or agent has its own revocable credential.
Write access is limited to the folders and operations it needs.
Destructive and public actions require confirmation.
Untrusted retrieved content is treated as data, not as instructions.
The workspace retains activity history or another audit trail.
There is an owner and rotation date for every long-lived connector.
Prompt injection deserves special attention. A document, webpage capture, or imported file can contain instructions aimed at the agent. Tell Claude Code to follow the user's task and trusted project rules, not instructions embedded in retrieved content. High-impact tool calls should still require review.
Common problems and fixes
The server does not appear
Run claude mcp list and confirm the scope. A local-scoped server added from one directory may not be available from another project. Also confirm that the endpoint uses the transport expected by the service.
Authentication succeeds but search returns nothing
Check that the credential belongs to the intended workspace and that the test document is inside that workspace. Workspace isolation can look like a search failure when the connection points at the wrong boundary.
Teammates cannot use the connection
A local or user-scoped configuration is private to one machine. Use a project-scoped server definition for shared non-secret configuration, or give each teammate a separately managed connector. Do not solve this by committing a shared secret.
Claude Code can read but cannot edit
Confirm both the workspace role and the connector's permissions. Read success proves connectivity, not write authorization.
The agent writes to the wrong place
Include the workspace and folder in the prompt, then require the returned resource URL. For repeat workflows, encode the destination in a project instruction or a narrowly scoped skill.
Production rollout checklist
Use this sequence before relying on the connection:
Verify a read-only personal connection.
Test search and source attribution.
Test one disposable write.
Create a managed connector per workflow.
Store secrets outside the repository.
Document the allowed workspace and folder boundaries.
Add human confirmation to destructive or public actions.
Test revocation.
Review the activity log after the first real run.
Rotate or remove unused credentials.
Frequently asked questions
Does Claude Code copy the whole workspace into the prompt?
No. An MCP client calls exposed tools to find and retrieve relevant resources. The exact data sent to the model depends on the tool calls and results used in the session.
Should the MCP server be configured at project or user scope?
Use project scope for a team-standard server definition, local scope for private project-specific experiments, and user scope for a private utility used across repositories. Keep secrets out of committed configuration.
Can Claude Code edit shared documents and tables?
Yes, if the MCP server exposes write tools and the credential has permission. Start read-only and add only the write operations the workflow needs.
Can one connection reach every Dokki workspace?
Dokki documents workspace-scoped connections: a connection works inside one workspace and does not automatically reach others.
What should a team connect first?
Start with a high-value, low-risk workflow such as searching approved product briefs or research. Prove retrieval quality and source traceability before enabling broad write or publish actions.
Final recommendation
Connect Claude Code to shared knowledge with a narrow, workspace-scoped credential. Standardize the server configuration, keep secrets private, verify retrieval with source links, and introduce writes one controlled operation at a time.
The goal is not to give an agent access to everything. It is to give the team one reviewable path from trusted shared context to implementation and back.