Select model capabilities on the website

The Models dialog in the version workspace declares the model slots the Program truly depends on. An LLM is required. Select image, video, audio, PDF, or image-understanding capabilities only when the Program uses them. Saving the selection does not replace a representative Workspace test.

An active CLI Workspace result includes the current managed-model capability summary. Treat that result as authoritative and do not infer roles that are absent. During development, model configuration may follow the OpenClaw 2026.6.11 schema, subject to these rules:

• Do not store real API keys, base URLs, Cookies, or authentication state in business files.
• Select every model capability the Program actually uses on the website, and pass at least one representative business request for each.
• If a used capability has no platform model available, stop publication. Do not remove the capability and describe the version as passed.
• External model calls made directly by a Plugin, Skill, MCP server, or business module are outside automatic platform replacement. The developer remains responsible for authorization, compliance, and reliability.

Resources configures CPU and memory only

The current Resources dialog selects CPU and memory, both of which are required before publication. It does not install Plugins or register MCP, A2A, or WebUI ports. Implement authorized integrations in /oasn and the OpenClaw configuration, then test each one separately in an active Workspace. WebUI ports are configured through CLI 0.7.3, not through a website form.

Implement extensions in the Workspace

OpenClaw Plugin

The standard location for a Workspace Plugin is /oasn/.openclaw/extensions/<plugin-id>/. Use the Plugin's own linked-install procedure only when it lives outside the standard location or its instructions explicitly require an installation record. In every case, inspect the actual runtime surface:

openclaw plugins inspect <plugin-id> --runtime --json

Keep both kinds of acceptance evidence:

1. inspect --runtime --json shows the expected Tool or hook in the real runtime; and
2. a request sent to main in WebChat actually triggers the Plugin and produces the expected result.

A normal list, an inspect without --runtime, the presence of a directory, or an installation log proves only that configuration or a manifest exists. It does not prove that the Plugin is working.

Reload the managed Gateway

Run the following managed operation only after the developer explicitly requests a reload and you have entered the current active Workspace with the complete SSH command returned by CLI:

sudo -n sh -lc '
set -eu
pid_file=/root/.openclaw/.oasn-developer-workspace/gateway.pid
test -r "$pid_file"
pid="$(cat "$pid_file")"
test "$(ps -p "$pid" -o comm= | xargs)" = "openclaw"
kill -USR1 "$pid"
'

Then inspect /root/.openclaw/.oasn-developer-workspace/gateway.log, confirm there is no ignored/error entry, verify http server listening and gateway ready, and submit one real WebChat request.

Platform paid API MCP

CLI 0.7.3 may return paid_api_mcp_status, paid_api_mcp_url, and paid_api_mcp_expires_at in the current Workspace summary. An active Workspace receives short-lived credentials from the platform. Use only the URL returned for that Workspace; never derive it from another environment, a previous session, or a hostname pattern.

After the developer authorizes the Sandbox configuration change, replace the placeholder with that exact URL and preserve the single quotes so the shell does not expand the token placeholder:

sudo -n openclaw mcp set oasn-paid-api '{"enabled":true,"transport":"streamable-http","url":"<paid_api_mcp_url>","headers":{"Authorization":"Bearer ${OASN_PAID_API_MCP_TOKEN}","X-OASN-MCP-Auth-Mode":"OASN_DEVELOPER"}}'

Reload the managed Gateway as described above, then use the controlled helper:

sudo -n oasn-paid-mcp probe
sudo -n oasn-paid-mcp list-tools
sudo -n oasn-paid-mcp tools --include '<tool>'

• Select canonical Tool names returned by list-tools; do not copy aggregate aliases or MCP Resource helper operations.
• The include list must contain unique, exact Tool names and no wildcard. Do not persist a meaningless empty exclude list.
• Exercise every selected Tool with a representative request during development.
• If the helper reports missing or expired credentials, stop. With explicit approval, run workspace resume for that same Workspace; do not read /proc, copy tokens, or switch authentication methods.

Agent to Agent (A2A)

The Developer Workspace does not guarantee that platform A2A is available. Depend on it only when an authorized, explicit integration exposes openagent_agent_run in the real Tool list. If it is absent, record BLOCKED and do not call an internal Access API directly. A call uses agent_id, idempotency_key, and data; use an agent_session_id only when continuing a trusted result. Reuse the same idempotency_key for retries of the same business intent.

Evaluate an A2A call in this order:

1. confirm that Tool transport completed;
2. check top-level isError first;
3. then inspect business state such as structuredContent.status; and
4. finally verify that any text, attachment, or WebUI result is genuinely usable.

A target Agent saying “completed” does not prove that its attachment can be downloaded or its page can be opened. Validate those outputs separately.