🪢 Agentspace — Dev Workspace API for Sharing Agent Files

Dev tool, HTTP API, and dev workspace for AI agent development. Watch live what an agent is doing, debug stuck runs, inspect agent files in real time, stream...

Security Scan

The skill's stated behavior (only upload a user-named path to agentspace.so and not read env/config) mostly matches its instructions, but the docs reveal the CLI and config files can read environment variables and store claim tokens, and the skill suggests running unpinned npm packages — these inconsistencies and the potential for sensitive tokens/configs to be uploaded make the package suspicious.

Purpose & Capability

The name/description (dev workspace, share folder, watch agent runs) aligns with the instructions to call the ascli CLI or npx @agentspace-so/ascli and to return a share URL. Requiring a CLI or npx is reasonable for this purpose.

Instruction Scope

SKILL.md repeatedly asserts the skill 'does not read environment variables, shell history, or files outside the path the user specifies.' However the developer reference explicitly documents that the daemon resolves the API server using .ascli.json, ~/.config/ascli/config.json, and the AGENTSPACE_API_BASE_URL environment variable. Using the ascli binary (or npx-pulled package) means those files/env vars may be read or created by the CLI even if the skill's prose claims otherwise. The skill instructs running ascli share <path>, which will upload the specified path, but there's a mismatch about whether any env/config read occurs.

Install Mechanism

There is no install spec in the registry (instruction-only). The SKILL.md recommends using an official npm package via npx or npm install -g @agentspace-so/ascli@latest. Pulling code with npx/npm is a normal approach for CLIs, but npx @latest is unpinned and executes remotely-published code, which is moderate risk compared with a vetted, pinned release or built-in binary. The skill explicitly forbids piping remote scripts into a shell, which reduces one high-risk pattern.

Credentials

The skill metadata declares no required environment variables, but the developer docs say the CLI uses AGENTSPACE_API_BASE_URL and reads config files and .ascli.json. .ascli.json contains an anonymous claim token (sensitive because anyone with it can read/write the workspace). The absence of declared env requirements in the metadata but explicit env/config use in the docs is an inconsistency that could cause accidental disclosure or redirection of uploads if environment/config is modified.

Persistence & Privilege

always:false and normal agent invocation are appropriate. The workflow will create a .ascli.json binding file in the shared folder that contains a claim token; committing or sharing that file can expose the workspace. The skill also documents agent-to-agent handoffs (OpenClaw), which is within its stated purpose but increases the blast radius of any shared workspace token. These are expected behaviors for a sharing tool, but they are worth user attention.

What to consider before installing

This skill appears to do what it says (share a user-named folder to agentspace.so), but there are some mismatches you should be aware of before installing or running it: - The SKILL.md claims it won't read env vars or other files, but the CLI it instructs you to run can read/set a config file and the AGENTSPACE_API_BASE_URL env var. Verify you have not set AGENTSPACE_API_BASE_URL to an unexpected host and check ~/.config/ascli/config.json if present. - The CLI creates a .ascli.json in the shared folder containing an anonymous claim token. Do not commit or share that file unless you intend to grant access to the workspace. Treat the claim token like a short-lived credential. - The instructions recommend using npx @agentspace-so/ascli@latest (unpinned). If you need stronger supply-chain guarantees, consider installing a pinned version or reviewing the package source beforehand. - Before running any share/sync, explicitly confirm the exact path to upload (do not rely on defaulting to .) and avoid including directories with secrets. - If you want higher assurance, verify the npm package publisher, inspect the ascli code you will run, and confirm the API base is agentspace.so (or a trusted local test URL) before executing. If you need help checking any of the above, provide the output of ascli --version and the value of AGENTSPACE_API_BASE_URL (if set) or the contents of ~/.config/ascli/config.json (do not include secret tokens).

🪢 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.