Claude Code as a Service: Running It for Many Users

Quick answer

Claude Code as a service means one isolated session per user

Running Claude Code as a service means giving each user's work its own isolated, persistent Claude Code session, with streamed progress, files and artifacts. It does not mean putting one claude -p process behind an HTTP endpoint.

Picture one request. A user of your product types "build me a landing page for my bakery" into a form. Your server turns it into a Claude Code run in a workspace that holds only that user's files, and your interface streams the run's progress as it happens. The user ends with a folder of HTML and images to preview and download. The next morning they ask for a darker header, and the same session picks up with the same files and the same conversation.

The private workspace, the long-running process, the conversation that resumes and the record of what ran all belong to the session. So the per-user session is the unit you have to provide when Claude Code serves many users. For the category itself, see what harness as a service means.

The common approach

A shared claude -p wrapper can leak context between users

Claude Code's headless mode makes the wrapper look finished. claude -p runs a prompt non-interactively, --output-format stream-json --verbose emits newline-delimited JSON events (add --include-partial-messages for token-level deltas), --output-format json returns a session_id, and --resume <session_id> continues that conversation later (Claude Code headless docs, checked 2026-10-26; flag behavior changes between releases, so check the docs for your version). Put that behind an endpoint and it works for one trusted person, such as you.

The second user meets everything the wrapper shares. By default, a -p run loads hooks, skills, MCP servers, auto memory and CLAUDE.md from the working directory and from ~/.claude, as an interactive session would; the --bare flag turns that auto-loading off. A default run also executes a project's hooks and connects its .mcp.json servers with no workspace trust prompt. Anthropic's hosting guide warns about the Agent SDK's default loading of settings and CLAUDE.md memory files: in a shared container serving multiple tenants, those files "can leak one tenant's context into another tenant's session" (Hosting the Agent SDK).

From that documented behavior we infer three problems when several users share one wrapper process:

• Workspace: every run starts in the wrapper's working directory unless you pass another, so one user's run can read and edit files that another user's run created.
• Credentials: the run reads ANTHROPIC_API_KEY from its environment, and an agent with a shell can read its own environment, so any user can prompt the agent to print your key.
• Conversation: --continue resumes the most recent conversation, which in a shared process belongs to whoever ran last.

Each fix is per user: a separate directory, a key the agent cannot read, a session ID stored against the right account. A wrapper is built for one trusted user; a tenant needs a session of their own. Hosted alternatives to a CLI wrapper walks through the wrapper path in detail.

What each session needs

Every user's Claude Code session needs four things someone has to operate

Anthropic's docs describe the shape: the Agent SDK "spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk," and "one agent session maps to one subprocess" (Hosting the Agent SDK). Isolation, concurrency, continuity and accountability each attach to that subprocess and its disk, so each has to exist once per session, and every session belongs to exactly one user.

• Isolation: each session needs a filesystem, config directory and network policy that no other user can reach. Inside a shared container, Anthropic's hosting guide says to turn off settings auto-loading (settingSources: [], or setting_sources=[] in Python) and auto memory (CLAUDE_CODE_DISABLE_AUTO_MEMORY=1), and to give each tenant its own config directory (CLAUDE_CONFIG_DIR), working directory (cwd) and network egress rules. A sandbox per session also decides how far you can relax permission prompts: see Claude Code permission modes under isolation and agent sandboxing, build or bundle.
• Concurrency: each run is a long-lived process whose memory grows with session length, and the SDK has no overall session timeout, so you cap each run's agent turns with maxTurns. If you run the SDK yourself, serving many users takes a queue, hosts sized by per-session memory, and either routing that pins each long-running session to the host running its subprocess or ephemeral containers that rehydrate the session from a SessionStore.
• Continuity: transcripts under ~/.claude/projects/, CLAUDE.md memory and working-directory files live on local disk, and none of them survive a container restart, a scale-down or a move to another node. A SessionStore adapter mirrors transcripts to durable storage. If you run the SDK yourself, the working-directory files and CLAUDE.md need their own volume or object-store sync.
• Accountability: each run needs a record your team can open later, showing which user, which configuration and what the agent did. The SDK exports OpenTelemetry metrics and logs once you set CLAUDE_CODE_ENABLE_TELEMETRY=1 and an OTLP endpoint, with traces behind the CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 flag; prompt text and tool inputs are left out unless you opt in. For cost, --output-format json reports total_cost_usd, which the docs call a client-side estimate, and why Claude Code gets expensive explains where a session's cost comes from.

If you assemble the system yourself, your team runs all four for every user, alongside the other backend layers an agent product needs. Through HarnessRouter Cloud they come bundled: each task runs in its own isolated sandbox, with concurrent runs, persisted sessions and files, streamed progress and a trace for every run.

Choosing a path

Three ways to run Claude Code for many users

The first path is to assemble it yourself. You run the Claude Code CLI or the Agent SDK, which the docs describe as "a library that runs the Claude Code binary" in "a process you operate," and add the sandbox, queue, session storage, file storage, streaming relay and telemetry around it. Anthropic's hosting guide and hosting cookbook cover the sandbox, session storage, scaling and telemetry.

On this path, use an API key for your users' sessions, not a claude.ai login. The Agent SDK docs say: "unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK" (Agent SDK overview, checked 2026-10-26). Anthropic's Commercial Terms govern use of the SDK.

The second path is Claude Managed Agents. Anthropic hosts what its docs call a "pre-built, configurable agent harness" for Claude, with sessions in an Anthropic-managed cloud sandbox or a self-hosted sandbox, results streamed as server-sent events, and event history persisted server-side (Managed Agents overview). On the check date it is in beta, behind the managed-agents-2026-04-01 beta header, and it runs Claude models only. It is Anthropic's own hosted harness, configured through the Claude API; its docs do not say it runs the Claude Code CLI, so check that the skills, tools and MCP servers your feature relies on are available in its agent definition. Managed agents compared goes further.

The third path is HarnessRouter. Claude Code runs as one of the supported harnesses behind one Agent API, and on HarnessRouter Cloud the platform operates the sessions; the next section shows how. How this sits beside the SDK and managed options in general is covered in Agent SDK, managed agents, agent CLI and HarnessRouter.

The three paths also combine. A team can self-host one feature on the Agent SDK and run another through a hosted service. A self-hosted CLI or SDK run can send model traffic through a model router or AI gateway by pointing the ANTHROPIC_BASE_URL environment variable at it.

The table below shows how each path delivers per-user agent sessions for a Claude Code feature, from each vendor's documentation as checked on 2026-10-26. In the HarnessRouter column, the sandbox, persistence, streaming and run-record rows describe HarnessRouter Cloud; self-hosting is Community Edition, on the same API contract.

If your team wants to own every layer, assemble it. Managed Agents is Anthropic's hosted, Claude-only option; evaluate its agent definition against the skills, tools and MCP servers your feature requires. If you want the sessions operated for you, a self-hosted option on the same API, and other supported harnesses beside Claude Code, run Claude Code through HarnessRouter.

How HarnessRouter runs it

HarnessRouter runs the sessions, your product keeps the users

HarnessRouter is the world's first unified interface for agent harnesses.

The unified interface is one Agent API to run every supported harness, Claude Code included, covering task execution, sessions, files, streaming and results. Each task runs in a serverless, isolated sandbox, with tracing to understand each run and optimize the Harness × Model configuration for each task.

Each end-user request becomes one call to POST /{harness_id}/v1/responses, where {harness_id} names an agent you configured on the claude-code base. Each call is a task. The first streamed event, response.created, carries response.id and response.metadata.session_id, which your server stores against the user. A task that starts a new session gets a private working directory: HarnessRouter's docs state that two tasks never see each other's work. The only way for a later task to reach those files is to continue the same session, below. The environments docs describe what else the sandbox provides.

A follow-up task sent with previous_response_id joins the same session, so it runs with the same working directory, conversational context and configured harness. The session's files come back through /v1/sessions/{session_id}/files, including a zip archive of the generated artifacts with their folder structure (sessions and files).

Your product keeps what it already owns: the interface, sign-in and the mapping from users to sessions. HarnessRouter returns opaque session and file IDs, and the multi-tenant authorization guide shows how your server checks that the signed-in user owns a session ID before each call on that session.

HarnessRouter Cloud delivers agent harness as a service, so running Claude Code through it is Claude Code as a service. Cloud manages concurrent runs, so a team scales from a single run to multiple parallel runs without provisioning or maintaining sandbox capacity. Community Edition ships the same API contract as a single Docker container on infrastructure you control, with model-provider credentials, application state and files under your control.

Every run on HarnessRouter Cloud leaves a trace with the selected harness, model, session status, elapsed time and a timeline of user messages, agent steps, tool calls and results. Your server ties each trace to the end user through the session ID it stored, and the trace lets you compare configurations and choose one per task.

In Care Prep, one recorded HarnessRouter task, each configuration ran five times. Claude Code with Claude Opus 4.8 succeeded in three of five runs (60%), with a p95 latency of 3m 41s and a cost of 223 credits. Hermes with GPT-5.2 succeeded in all five runs, with a p95 latency of 2m 33s and a cost of 0.47 credits. That result describes this one task; on your own tasks, the same API and trace let you test Claude Code against another supported harness and keep the configuration that meets your quality bar. Codex vs Claude Code through an API compares two harnesses on the same task.

"We literally can go from a problem and a plan into an agent that is in prod within 24 hours," Edward Tiong, co-founder and CEO of Readily (YC S23), said in HarnessRouter's August 2026 launch announcement.

Next step

Start with one real user request

• Create an API key in the HarnessRouter quickstart and keep it on your server.
• Configure an agent on the claude-code base with the instructions, tools and skills your feature needs.
• Send one real user request as a task with stream: true, and store response.id and response.metadata.session_id against that user.
• Send a follow-up request, such as the darker header from the opening example, with previous_response_id, then download the session's files.
• Add the ownership check to every call on an existing session, then open the feature to more users.

FAQ

Common questions

Keep reading

Related reading

• What is harness as a service?
• Hosted alternatives to a CLI wrapper
• Managed agents compared
• AI agent sandboxing: build or bundle
• The backend for AI agents