Virtual workspace

In Web Forge, your files live in the browser, not on a server. The virtual workspace is a key-value store backed by IndexedDB. The agent reads + writes via workspace_* tools.

How files get in

• Drag-drop files or folders onto the browser window.
• Paste a file from your clipboard (works for images and small text).
• Upload via the toolbar file picker.
• Create new via the agent: "create a file at src/api.ts with..."

Browser-local

The workspace is browser-local. Closing the tab doesn't lose it (IndexedDB persists across reloads), but clearing site data does. There's no server-side copy.

This means:

• Your code never touches our infrastructure as files. Only the model sees content during inference, and only for what the agent reads.
• Switching browsers / devices doesn't bring your workspace with you. Each browser has its own.

File operations

The agent has four tools for the workspace:

workspace_list()
workspace_read(path)
workspace_write(path, content)
workspace_edit(path, old_string, new_string)

workspace_edit is the surgical option - matches old_string exactly (whitespace + indent matters), replaces with new_string. Must match exactly once in the file. The agent uses it for targeted edits; workspace_write for new files or full rewrites.

Sandbox mirror

When you start a Web Forge session, the workspace files are mirrored into the sandbox container at /workspace/. The agent runs bash against that mirror:

> /workspace$ ls
package.json  src/  tests/
> /workspace$ pnpm test

Sandbox writes don't sync back. If the agent runs npm install in bash, the resulting node_modules lives in the sandbox - not the workspace. To update workspace files, the agent uses workspace_write / workspace_edit.

This split is intentional: it keeps the browser workspace clean (no node_modules bloat) while letting bash do real work in a Linux env.

Limits

Files larger than 1 MB are rejected at drag-drop. The agent gets a partial view if it tries to read one.

Download

When done:

• "Download workspace" button - bundles every file into a zip.
• Per-file download via the file list sidebar.

Sidebar UI

The file list shows:

• All workspace files, with their sizes.
• Modified indicators when the agent writes to a file.
• Click to preview content in a side panel.
• Diff view for files modified this session.

Visibility to the agent

When the workspace has files, the system prompt includes a summary (path + size) for the first 80 files. Workspaces with more than 80 files show a count and tell the agent to use workspace_list for the rest.

Empty workspaces get a note: "user hasn't uploaded any files yet - if they ask code questions without files, answer directly; suggest they drag-drop files for in-place editing."

Common patterns

Quick code review:

Drag the file in. Ask: "review this for bugs."

Multi-file refactor:

Drag the whole src/ directory in. Ask the agent to refactor across files. Each edit shows in the sidebar with a diff.

Generate from spec:

Drag a spec.md in. Ask: "implement this spec." Files appear in the workspace as the agent creates them.

Iterate on a prototype:

Start empty. "Build a TypeScript HTTP server with a /health endpoint and tests." Files materialize. Download when done.

Privacy

Workspace data lives in your browser's IndexedDB. Content sent to the model during inference flows through the IsonAI gateway like any prompt. For sensitive code, ensure your deployment + retention policy align.

When you close the tab, the workspace stays in IndexedDB. To wipe it: clear site data in your browser settings, or click "Clear workspace" in the toolbar.

Limits compared to CLI

For real projects: CLI. For quick experiments + sharable sessions: Web.