Run a coding agent in a workspace
A coding agent produces changes to a workspace. Wildo gives that work an execution path distinct from generating text or an image, with a declared agent provider and execution profile.
The runtime manages the session, task exchange and cancellation. The application chooses the agent and the host policies under which it may run.
Example — Implement a change in an application
A development workflow hands a coding task to a registered agent. The run records the agent binding and returns the coding outcome; the changed workspace can then be inspected and verified.
For engineers
This excerpt adapts the companion’s registered binding; ApplicationCodingAgentBinding is its application-owned type. The matching execution profile must be authored in runtime configuration. It keeps provider, model and execution profile together. A coding agent requires executionProfileRef; unlike a language-model API call, it cannot omit the authority and environment under which its subprocess runs.
const codingAgentBinding = {
ref: 'application-coding.agent',
displayName: 'Application Coding Agent',
providerRef: 'anthropic',
executionProfileRef: 'claude-code-acp',
model: LLM_Model.CLAUDE_OPUS_5,
} satisfies ApplicationCodingAgentBinding;
The ACP runner negotiates the protocol, opens or resumes the session, exchanges turns and answers permission requests. Enforcement depends on which callbacks the provider actually raises. The dispatch layer checks the provider’s declared permission-escalation behavior before accepting a restrictive ceiling. Do not describe mutation scope as an operating-system sandbox: a child doing its own I/O without a relevant callback is a different boundary, and the recorded run/change set remains important.
Author the matching companion execution profile
The binding above names claude-code-acp. Declare that same key under providerConfigurations.anthropic[ExternalProvider_ExchangeProtocol_Kind.AGENT_CLIENT_PROTOCOL].executionProfiles in wildo.saas.config.ts. This selected profile follows Wonder Todos’ development setup; the omitted settings govern recording and data-processing declarations, not provider selection. The AgentClientProtocol_* enums, APPLICATION_ENVIRONMENT and ExternalProvider_ExchangeProtocol_Kind come from @wildo-ai/external-connectors-models.
providerConfigurations: {
anthropic: {
[ExternalProvider_ExchangeProtocol_Kind.AGENT_CLIENT_PROTOCOL]: {
defaultExecutionProfileRef: 'claude-code-acp',
executionProfiles: {
'claude-code-acp': {
runnerHost: AgentClientProtocol_RunnerHost.BACKEND_SUBPROCESS,
authMode: AgentClientProtocol_AuthMode.HOST_MANAGED,
allowedApplicationEnvironments: [APPLICATION_ENVIRONMENT.DEVELOPMENT],
workingDirectoryPolicy: AgentClientProtocol_WorkingDirectoryPolicy.WORKSPACE_ROOT,
permissionCeiling: AgentClientProtocol_PermissionCeiling.UNRESTRICTED,
hostConfigurationInheritance: AgentClientProtocol_HostConfigurationInheritance.APPLICATION_SCOPED,
turnTimeoutMs: 30 * 60_000,
maxAutoContinuations: 12,
awaitingInputTtlMs: 30 * 60_000,
},
},
},
},
},
HOST_MANAGED uses the operator’s existing agent login. The provider owns its launch command; the host supplies the workspace at invocation. The unrestricted ceiling admits all tool categories; declared locations and available approval options still govern individual requests. It is not a sandbox: filesystem confinement still depends on participating callbacks, and the host must inspect the resulting changes.
Enable EngineCapability.AI_CODING_AGENT, then merge this entry into providers.scopes.companion.providers. EngineCapability comes from @wildo-ai/saas-models. An AI_LLM backend entry cannot substitute for this companion transport:
anthropic: {
engineCapabilities: [EngineCapability.AI_CODING_AGENT],
providerCapabilities: ['CODING_AGENT'],
protocols: ['AGENT_CLIENT_PROTOCOL'],
},
Run wildo config sync after configuration changes. The host needs the provider’s supported agent installation and login before dispatch; selecting a model does not install or authenticate the subprocess. Application runtime language generation has its own backend provider setup.
Dispatch the task in a trusted workspace
The companion constructs this invocation after admitting its typed task and rendering the task prompt. A resumed run supplies the operator’s answer and the existing session ID; a new run supplies the rendered task.
const invocation: FlowsActors_Agent_Invocation<
typeof CodingAgent_RunTaskInputSchema,
typeof CodingAgent_RunTaskOutputSchema,
typeof CodingAgent_OperationContext_BaseSchema
> = {
agentRef: APPLICATION_CODING_AGENT_REF,
initiator: {},
invocationContext: [],
input: resume
? { prompt: resume.answerPrompt, continuationOfSessionId: resume.continuationOfSessionId }
: { prompt: renderedPrompt },
output: { finalMessage: '', stopReason: CodingAgent_StopReason.END_TURN },
executionContext: { callTimestamp: new Date().toISOString() },
artifactBindings: [],
};
The call also receives the trusted workspace and task-location predicate. This reduced excerpt omits the companion’s event collection and turn-classification callbacks; it shows where workspace and cancellation enter the runtime:
const response = await this.agentsService.invokeAgent(
invocation,
traceContext,
{
workspaceRootPath: this.companionContext.saasRoot,
isPermittedCodingLocation: buildApplicationCodingTaskLocationPredicate(
this.companionContext.saasRoot,
task.mutationScope.allowedPathPrefixes,
task.mutationScope.prohibitedPathPrefixes,
),
...(this.activeRun ? { codingSessionAbortSignal: this.activeRun.abortController.signal } : {}),
},
);
const codingOutput = response.output as Partial<CodingAgent_RunTaskOutput> | undefined;
const text = codingOutput?.finalMessage;
const stopReason = codingOutput?.stopReason;
finalMessage is not itself acceptance of the changes. The host checks the stop reason, records the run and inspects the resulting change set. A parked run is asking for input, not reporting a finished implementation. Permission callbacks constrain participating operations; they do not turn arbitrary subprocess I/O into a filesystem sandbox.