- MCP Server ToolsUpdated
- Managed MCP with chat()Updated
- Manual MCPUpdated
- MCP Type GenerationUpdated
- MCP Client InputUpdated
- MCP Server Tools: AdvancedNew
- MCP EventsNew
- MCP AppsUpdated
- Serve Tools over HTTPUpdated
- Serve Resources and PromptsUpdated
- Ask for InputUpdated
- Draft Text from a ToolUpdated
- MCP Server TasksUpdated
- MCP Server AuthUpdated
- MCP Server SessionsUpdated
- MCP Server on stdioUpdated
Persistence (Advanced)
- GenerationsUpdated
- Realtime Voice ChatUpdated
- Text-to-SpeechUpdated
- TranscriptionUpdated
- Transcription: AdvancedNew
- Voice CreationUpdated
- Audio RecordingUpdated
- Audio GenerationUpdated
- Image GenerationUpdated
- Image Generation: AdvancedNew
- Video GenerationUpdated
- Video Generation: AdvancedNew
- Live GenerationUpdated
- World GenerationUpdated
- Generation HooksUpdated
- Build your first harnessUpdated
- Host optionsNew
- Send and show mediaUpdated
- Connect clientsUpdated
- Write a client in any languageNew
- Access and tenantsNew
- Run in the terminalUpdated
- Deploy a harnessUpdated
- Send inputs safelyUpdated
- Run a tool without a model
- Durable sessionsUpdated
- Run background work on workersNew
- List, rename, and fork sessionsUpdated
- Lifecycle and retentionNew
- Run side effects onceUpdated
- Wait for a personNew
- Build on the session logUpdated
- Control how a turn endsUpdated
- Store settings per threadUpdated
- Compact a long sessionUpdated
- Fork and reset a threadUpdated
- One log for a session treeUpdated
- Write a pluginUpdated
- Track usage and costUpdated
- Ask before risky tool callsUpdated
- Give your agent coding toolsUpdated
- Sandbox and extend the coding toolsUpdated
- Run the coding tools for many threadsNew
- Undo a turnUpdated
- Build a coding agentUpdated
- Delegate to coding agentsUpdated
- Switch between agent profilesUpdated
- Auth and connectorsUpdated
- Share a thread between peopleUpdated
- Connect model providersUpdated
- Build your own UIUpdated
- Code mode in a harnessUpdated
- Work until a goal is metUpdated
- Run agents from a harnessUpdated
- Hand off a conversationNew
- Add skillsUpdated
- Use MCP serversUpdated
- Give your agent a computerNew
- Use from any MCP clientUpdated
- Use a harness from an editor (ACP)Updated
- OverviewUpdated
- Quick StartUpdated
- ProvidersUpdated
- HarnessesUpdated
- Harness AuthUpdated
- WorkspaceUpdated
- ToolsUpdated
- PolicyUpdated
- Lifecycle & SnapshotsUpdated
- Portable SnapshotsUpdated
- Keep Files After ReloadUpdated
- Save a Named VersionUpdated
- Branch From a VersionUpdated
- Send a Frozen FileUpdated
- Let the Agent Save and ForkUpdated
- Pick Which Files to KeepUpdated
- What a Snapshot StoresUpdated
- Instance DurabilityUpdated
- Durable RunsUpdated
- EventsUpdated
Sandboxes (Advanced)
- Runtime ContextUpdated
- Bring Your Own KeyUpdated
- Keep Keys on the ServerUpdated
- Debug LoggingUpdated
- Multimodal ContentUpdated
- Files APIUpdated
- Per-Model Type SafetyUpdated
- Runtime Adapter SwitchingUpdated
- Tree-ShakingUpdated
- Extend AdapterUpdated
- Extend Adapter: AdvancedNew
- Typed Pre-Configured OptionsUpdated
- Test with a Fake ModelUpdated
- Prompt CachingUpdated
- Mid-Conversation ChangesUpdated
- Approval Flow ProcessingUpdated
Delegate to coding agents
Your lead agent plans the work, but you want Claude Code or Codex to do the edits, because they are good at code and you already use them. codingAgents gives the lead model one tool per coding agent. Each agent works in a sandbox and keeps its own session between calls.
1. Add the plugin#
npm i @tanstack/ai-harness @tanstack/ai-sandbox @tanstack/ai-sandbox-local-process @tanstack/ai-claude-code @tanstack/ai-codexpnpm add @tanstack/ai-harness @tanstack/ai-sandbox @tanstack/ai-sandbox-local-process @tanstack/ai-claude-code @tanstack/ai-codexyarn add @tanstack/ai-harness @tanstack/ai-sandbox @tanstack/ai-sandbox-local-process @tanstack/ai-claude-code @tanstack/ai-codexbun add @tanstack/ai-harness @tanstack/ai-sandbox @tanstack/ai-sandbox-local-process @tanstack/ai-claude-code @tanstack/ai-codeximport { defineHarness } from '@tanstack/ai-harness'
import { permissions } from '@tanstack/ai-harness/plugins'
import { claudeCodeText } from '@tanstack/ai-claude-code'
import { codexText } from '@tanstack/ai-codex'
import { openaiText } from '@tanstack/ai-openai'
import { defineSandbox, defineWorkspace, localSource } from '@tanstack/ai-sandbox'
import { codingAgents } from '@tanstack/ai-sandbox/harness'
import { localProcessSandbox } from '@tanstack/ai-sandbox-local-process'
const repo = '/path/to/your/repo'
export const lead = defineHarness({
name: 'acme/lead',
adapter: openaiText('gpt-6.1-sol'),
plugins: () => [
permissions(),
codingAgents({
sandbox: defineSandbox({
id: 'repo',
provider: localProcessSandbox({ dir: repo }),
workspace: defineWorkspace({ source: localSource(repo) }),
}),
agents: {
claude_code: {
adapter: claudeCodeText('claude-opus-4-8', { permissionMode: 'acceptEdits' }),
description: 'Larger changes, refactors, and reviews',
},
codex: {
adapter: codexText('gpt-5.3-codex', { sandboxMode: 'workspace-write' }),
description: 'Quick fixes and tests',
},
},
}),
],
})localProcessSandbox({ dir: repo }) works in your repo folder itself, so every thread and every agent shares that folder. Leave out dir to give each sandbox its own copy of the repo.
The lead model now has a claude_code tool and a codex tool. Each tool takes one task: the whole job, in words. The agent sees only that text and the files in its sandbox.
2. Ask for work#
Open a session, and give the lead a task for both agents:
import { createHarnessHost } from '@tanstack/ai-harness'
import { memoryPersistence } from '@tanstack/ai-persistence'
const host = createHarnessHost({ persistence: memoryPersistence() })
const session = await host.open(lead, { threadId: 'date-parser' })
const turn = await session.send(
'Have claude_code add a test for the date parser, then have codex fix what fails.',
)
console.log(turn.text)The lead calls claude_code with a task, and gets back its answer. Then it calls codex. Each agent works in the same sandbox, one after the other.
Sessions#
Each agent keeps its own session per harness thread. The next task for claude_code resumes the same Claude Code session, so it still knows the files it read. The session ids live in the plugin state, so they also survive a restart of the host.
To start over, run /fresh claude_code, or /fresh for every agent.
Workspaces#
workspace chooses where the agents work:
| Value | Where each agent works | At the same time |
|---|---|---|
| 'shared' (default) | One sandbox per harness thread | One agent at a time |
| 'per-agent' | A sandbox per agent | Yes |
Use 'shared' when the agents build on each other's changes. Use 'per-agent' when they work on separate copies and you merge the results.
Only the host that owns the log of the thread runs its agents. So with many servers, 'shared' still runs one agent at a time.
Plan mode#
When the permissions() plugin is in plan mode, the agents start read-only:
- Claude Code gets permissionMode: 'plan'.
- Codex gets sandboxMode: 'read-only'.
- Any other agent gets its planModelOptions, for example { permissionMode: 'default' } for an ACP agent that asks before each edit.
- An agent with no planModelOptions does not run in plan mode. Its tool call gets an error.
Other agents and sandboxes#
- adapter takes any coding-agent adapter: grokBuildText from @tanstack/ai-grok-build, or acpCompatibleText from @tanstack/ai-acp for any ACP agent.
- sandbox takes any sandbox provider. Sandbox providers lists them.
- modelOptions on an agent is added to every call, for example a fixed permissionMode.
What you have now#
- A lead model that hands tasks to Claude Code and Codex.
- One sandbox per thread, and one saved session per agent.