🪢 Agentspace — Dev Workspace API

Dev tool for AI agent development. Watch agent runs live, debug them through a workspace HTTP API, and share the result with another agent or a human reviewer when the run is done.

Built for the problem every agent developer hits: the agent is working in a folder, you can't see what it's doing, and asking the agent to self-report doesn't tell you the truth. ascli sync fixes that.

Primary dev use case: watch an agent run

When you're developing with an AI agent, the agent works inside a folder but you have no visibility into what it's doing unless it writes logs. ascli sync <path> turns that folder into an observable dev workspace:

1. Start the AI agent in a local folder.
2. Run ascli sync <path> to bind the folder to a remote dev workspace via the ascli HTTP API.
3. Open the workspace URL. This is your dev observability dashboard.
4. Watch the agent's file tree update live as it creates, edits, renames, deletes files.
5. Inspect any file in the in-browser editor — logs, generated scripts, screenshots, model outputs, anything the agent writes.
6. Debug stuck or misbehaving agents by reviewing intermediate state, without asking the agent to self-report.

This is the core dev observability loop for AI agent development.

HTTP API for devs

The ascli daemon is a thin client over the agentspace.so HTTP API. Key endpoints devs use directly when building custom dev tools or scripting workspace operations:

• POST /api/workspaces — create an anonymous dev workspace.
• GET /api/workspaces/:id/events — SSE event stream of remote changes; watch-mode dev tools subscribe here.
• POST /api/workspaces/:id/share-links — create a share link with edit or view permission.
• POST /api/openclaw/handoffs — agent-to-agent dev handoff, so one agent can pick up where another left off.

See references/developer.md for the full dev API reference and debug recipes.

CLI commands

• ascli sync <path> — bind a local dev folder to a workspace, then watch both sides.
• ascli share <path> --permission edit — get a share URL for a file or folder.
• ascli share <path> --permission view — view-only link.
• ascli status <path> — inspect the current dev workspace binding.

Choose the CLI path

1. If ascli is already on PATH, use it directly.
2. Else if npm is available, run without installing via npx @agentspace-so/ascli@latest <command>, or install once with npm install -g @agentspace-so/ascli@latest.
3. If neither ascli nor npm is available, stop and tell the user to install Node.js from nodejs.org first.

Do not pipe a remote script into a shell to install.

Share a path

• Ask the user which folder or file to share if they have not named one explicitly. Do not assume ..
• Run ascli share <path> --permission edit with the user-specified path.
• If the user asks for view-only access, use --permission view.
• share handles an unbound folder by creating a temporary workspace, syncing once, and returning a link — no separate sync step is needed for one-off sharing.
• Return the share URL directly to the user exactly as the CLI prints it.

Data handling

• Only the path the user explicitly names is uploaded. Do not default to uploading the current working directory unless the user clearly says so.
• All network traffic goes to agentspace.so only. The skill does not call any other endpoint.
• The skill does not read environment variables, shell history, or files outside the path the user specifies.

Guardrails

• Do not invent claim URLs, workspace URLs, or share URLs. Only return what the CLI prints.
• Do not require a global install if npx already works.
• Do not move the user into a different project just to use agentspace.so.
• If the user asks to "share this folder" and the target is ambiguous, confirm the exact path before running.
• If you need exact command variants, read references/commands.md.