paperclipai/paperclip · error
Session goals are unsupported by this agent.
Error message
Session goals are unsupported by this agent.
What it means
In the same useRunnerGoalControl action handler, once a runner has an agentId the code checks capability.availability. If it is anything other than "available", the goal action is rejected with the backend's capability.reason, falling back to the static message "Session goals are unsupported by this agent." This prevents issuing goals to agents/runners that do not implement session goals.
Source
Thrown at ui/src/components/task-chat/RunnerGoalWidget.tsx:100
if (current && next.revision > current.revision + 1) {
void query.refetch();
return;
}
if (!current || next.revision >= current.revision) queryClient.setQueryData(key, next);
});
const executeAction = useCallback(async (
action: RunnerGoalAction,
objective?: string,
confirmReplace = false,
expectedRevision?: number,
) => {
setActionError(null);
try {
const current = query.data ?? (await query.refetch()).data;
if (!current?.agentId) throw new Error(current?.capability.reason ?? "Select an agent to use /goal.");
if (current.capability.availability !== "available") {
throw new Error(current.capability.reason ?? "Session goals are unsupported by this agent.");
}
await mutation.mutateAsync({
requestId: requestId(),
agentId: current.agentId,
expectedRevision: expectedRevision ?? current.revision,
action,
...(objective ? { objective } : {}),
...(action === "replace" ? { confirmReplace } : {}),
});
} catch (error) {
setActionError(error instanceof Error ? error.message : "The goal action could not be applied.");
throw error;
}
}, [mutation, query]);
const edit = useCallback(async () => {
const current = query.data ?? (await query.refetch()).data;
if (!current?.goal) throw new Error("There is no current session goal to edit.");View on GitHub (pinned to 01ad858492)
Solutions
- Use an agent/adapter that supports session goals; switch the runner's agent if needed.
- Refetch the capability query — transient "unavailable" states resolve after the runner is healthy.
- Read capability.reason in the API response for the specific blocker when supplied.
- Upgrade the agent adapter to a version with session-goal support.
- Skip the goal UI for agents whose capability reports unsupported, so users see it disabled upfront.
Example fix
// before: blindly rendering the goal widget
<RunnerGoalWidget runnerId={id} />
// after: gate on capability
{capability?.availability === "available" ? (
<RunnerGoalWidget runnerId={id} />
) : (
<span>Goals unsupported for this agent</span>
)} Defensive patterns
Strategy: validation
Validate before calling
const cap = useRunnerGoalCapabilityQuery(runnerId).data; const goalsSupported = cap?.agentId != null && cap?.capability?.availability === "available"; if (!goalsSupported) disableGoalWidget(cap?.capability?.reason ?? "Session goals are unsupported by this agent.");
Type guard
const goalsAvailable = (cap: { capability: { availability: string } } | null | undefined): boolean =>
cap?.capability?.availability === "available"; Try / catch
try {
await runnerGoal.control({ action, goal });
} catch (e) {
if (e instanceof Error && e.message.includes("unsupported by this agent")) {
showNotice("This agent does not support session goals.");
} else throw e;
} Prevention
- Gate the goal UI on capability.availability === "available" before rendering.
- Surface capability.reason to users instead of the generic fallback.
- Prefer agents/adapters with session-goal support when goals are required.
- Refetch capability after runner restarts so transient states clear.
When it happens
Trigger: Invoking a goal action while the capability query reports availability !== "available" (e.g. "unsupported" or "unavailable") and no specific capability.reason is provided — typically an adapter/agent that lacks session-goal support.
Common situations: Using /goal with an agent adapter that has not implemented session goals; a temporarily unavailable runner marking capability as unavailable; older adapter versions predating goal support; stale capability data that a refetch would correct.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- Select an agent to use /goal.
- [adapter-ui-loader] Failed to load UI parser for "${adapterT
- Failed to seed CEO instructions:
- [paperclip] UI dist not found; running in API-only mode
- Select an organization to test adapter environment
AI-assisted analysis of paperclipai/paperclip@01ad858492 (2026-09-10).
Data as JSON: /api/errors/b95f8cddf4fc86e8.
Report an issue: GitHub.