Finding 6 of REVIEW-2026-07-30.md. runWithTimeout could not cancel anything,
because Provider.Execute took no context: the goroutine ran on to the HTTP
client's 60s timeout, outliving the 30s capability timeout. Provider.Execute
now takes a context carrying that timeout, and the workspace provider issues
its tool call with http.NewRequestWithContext, so a timed-out execution
actually tears the request down.
A read-only capability whose provider call times out now resolves to failed
rather than unknown. Spec §4.3 reserves unknown for executions whose side
effect may or may not have landed, and never retries them — which made read
failures both unretryable and indistinguishable from genuinely ambiguous
mutations, for calls that by definition have no side effect. Mutating
capabilities still resolve to unknown.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uea55zaiWuEByEDC4UBSdd
Decision: workspace-mcp's /api/tool, /api/tools direct-HTTP endpoints are
a first-class, server-sanctioned transport (see transport.py's "Direct
HTTP API for non-MCP clients"), not a workaround — Hexis's REST provider
is the right integration, no migration to the SSE/JSON-RPC MCP transport
needed.
The actual gap: workspace-mcp catches tool-handler exceptions and reports
them as an ERROR-coded warning inside a 200 response envelope rather than
an HTTP error status, so Execute()'s status-code check alone let every
such failure through as a successful execution. Detect the ERROR-coded
warning and return it as an error so it maps to Hexis's failed status.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018ghELqYhZNLub2TXGMazqA
kami