Pages (Beta)

Pages are persistent mini apps that an agent builds for you and that outlive the conversation. Ask for a build-health dashboard, a weekly report, a habit tracker, or a small calculator, and the agent creates a page that shows up as a tile in the Pages section of the sidebar and renders inside the app.

Pages are in beta. Expect rough edges, and tell us what you build.

What a page is

A page lives at {workspaceRootPath}/pages/{slug}/ and carries:

• page.json — the page's name, kind, project binding, refresh schedule, approved actions, and a digest of its content.
• index.html — one self-contained HTML document. All CSS and JavaScript are inline, and the page makes no network requests of its own.
• data/ — a small private data store: key-value entries for current values plus named time series for anything charted over time. The store is bounded (1000 keys and 100 series per page), and every write is transactional.
• A cached preview poster — captured automatically so the tile shows what the page looks like.

Agents manage pages through session tools (list_pages, get_page, create_page, update_page, write_page_data, delete_page) rather than editing the folder directly. The read-only tools stay available in Explore mode; the mutating ones do not.

Page kinds

Every page renders in a sandboxed frame with no same-origin privileges: no cookies, no local storage, no access to the app. Data reaches the page through a message bridge, never through fetch.

Working with pages

• Open the library from Pages in the sidebar. The grid can be filtered by project.
• Create a page by asking an agent. An empty library offers Design this with an agent to start.
• Rename a page inline from its header, and move it between projects from the page's ⋯ menu.
• Delete a page from the same menu. Deleting a page removes its data store and any approved actions.

Scheduled refresh

A page can carry a refresh schedule: a cron expression plus a script inside the workspace. When the schedule fires, the script runs in the background and updates the page's data. No agent session is created and no tokens are spent.

{ "cron": "*/15 * * * *", "script": "scripts/refresh-build-health.ts" }

Schedules are validated when saved. The expression must parse, must actually fire, and cannot run more often than every 5 minutes. Refresh failures are recorded on the page and surface in the app rather than failing silently.

Refresh scripts run under Bun with a minimal environment: FABRIC_WORKSPACE_PATH, FABRIC_PAGE_SLUG, FABRIC_PAGE_DIR, and FABRIC_PAGE_DATA_DIR, plus any other FABRIC_* variables you export. The script's working directory is the workspace root. Scheduled refreshes are the same mechanism as script automations, so the same containment rules apply.

Page actions and approvals

Interactive pages can trigger real calls against your sources. A "Send email" button can use a connected Google source, a "Refresh tasks" button can call an MCP tool, and a "Rebuild" button can run a workspace script. The page never sees credentials. It posts an action request, and the app validates it against an approval you granted and executes it on the page's behalf.

How approvals work:

• You approve each capability. When a page needs an action it does not yet have, the app shows an approval dialog describing the source, method, and path, MCP tool, or script involved.
• Approvals are bound to the exact page content and expire after 30 days. Editing the page's HTML invalidates its approvals, and the page simply asks again on next open.
• Anything that can change something requires a fresh click inside the page. Only read-only API calls may run without one. MCP tools and scripts always require a click.
• Every decision is logged to ~/.fabric-agent/logs/page-actions.jsonl, with sensitive values redacted.
• Remove any approval at any time from the page's ⋯ menu under Approved actions.

Script approvals are the highest-privilege action a page can take. The approval pins the exact script, runtime, and arguments. The page cannot change them at call time. A page that holds a script approval cannot be published.

Reconnecting a source

When a source a page depends on loses authentication, a banner above the page offers a one-click reconnect: OAuth, key entry, or a prefilled chat for multi-field setups. You do not have to leave the page.

Sharing pages

Pages can be published as view-only copies at a short link, optionally password protected, with the current data snapshot included only if you opt in. Published copies never execute actions, and the publish flow warns when the data looks like it contains secrets.

Use the Share button in the page header. The published copy is served from agents.fabric.pro/p/{id} inside the same kind of sandbox the app uses, with all network access blocked. Only the page's HTML, its title and description, and the data snapshot you opted in to leave your machine. The key that manages the public copy stays in your credential vault.

Sharing is on by default. Set FABRIC_FEATURE_PAGES_SHARING=0 in the app's environment to hide the Share button; FABRIC_PAGES_SHARE_API_URL points publishing at a different endpoint. Unpublishing always works regardless of the flag, so a published page can never be stranded.

Pages and projects

A page can be bound to a project. The Pages library filters by project, and pages created from a session bound to a project inherit that binding. See Projects.