Customize & account
Want to change Cial itself — add a harness, a tool, an integration, a whole feature? That's Extending Cial. This page covers the lighter knobs: what's visible, standalone apps, notifications, and your account.
Cial bends to your workflow on several axes: hide surfaces you don't use, open standalone apps, have the agent rewrite the product itself, get pinged when work finishes, and manage your plan. This page covers all of them.
Discovery: show or hide features
Settings → Discovery controls which optional surfaces are visible. Each has a switch; changes are per-user, sync instantly across your open tabs, and only affect visibility — nothing is deleted and the agent is unaffected. Everything is on by default.
Toggleable surfaces:
Where a feature has its own page (push, team channel), the Discovery switch is the master on/off; the dedicated page handles the deeper config.
Always on (listed with an "Always on" label, no effect when toggled): sessions, onboarding, harnesses, tools, skills, self-edit, and composer essentials (model picker + per-session tool controls). The app depends on these.
Cial Apps
A Cial app is a self-contained full-width surface — a dashboard, an admin console, a focused tool — that opens in the main pane beside your chat, in the same slot Settings uses. It's separate from the agent conversation, has its own address (so it survives a refresh and can be shared as a link), and switching back to a chat returns you exactly where you were. Plugin, extension, add-on, module, widget, integration — in Cial they all mean the same thing: an app you open from Apps.
Open one from Apps in the sidebar. New instances ship with none ("No apps yet"); apps appear once added to your instance. To get one, ask the agent in a session to build it — a Cial app registers through a single merge-friendly extension point, so it's a clean self-edit that keeps future upstream merges easy.
Three adjacent concepts: an app is a standalone surface (Apps area); a feature works inside the chat (sessions, knowledges, uploads); a Discovery setting shows or hides a surface you already have.
Self-editing & updates
Cial isn't configured from the outside — the agent rewrites it from the inside. Your instance ships with its own source tree on a persistent volume, and that tree is a git fork of a single canonical upstream. The agent edits files in the fork, rebuilds, and restarts the live process — all from an ordinary chat. Everything below follows from that.
The self-edit loop
You describe an outcome; the agent runs locate → edit → deploy → commit.
The deploy/commit verbs run for you — a normal self-edit ends with a commit:
cial-cli self deploy # rebuild client + restart server
cial-cli self restart # restart only (server-source changes)
cial-cli self commit "feat: …" # persist working tree to your fork
cial-cli self rollback # restore the previous client bundle
cial-cli self dist # inspect build manifest + rollback state
These calls travel the same authenticated path as the rest of the app: each turn
holds a short-lived, owner-scoped credential carried by cial-cli, hitting the
instance's own server over loopback as the owner. A process can't cleanly
restart itself, so an external supervisor babysits the server — on deploy or
restart the server exits with a special signal and the supervisor respawns it with
the new source + freshly built client (a crash is respawned after a backoff). That
is why a self-edit restart is routine and recoverable, not downtime.
Applied vs. saved
The git fork is the line between live and durable:
A change that's deployed but not yet committed can be lost if the instance is later rebuilt. If you ask only to "make it live," ask to "save it" too.
It's reversible: every commit is a checkpoint (ask to undo the last change or return to an earlier state), the client bundle can roll back independently of source if a build renders something broken, and committed work survives every restart. If you land somewhere you don't like, tell the agent plainly — "undo the last change" — and let it work out the steps.
Pulling in updates
Improvements ship to the canonical upstream every instance forks from. Because
your instance is a fork, updating is a git merge into your fork —
upstream is read-only to you, and your customizations are preserved.
A background check periodically compares your fork against upstream and pushes an update-available badge to the sidebar when you're behind (cached and off the hot path, so a fresh tab gets the current state). To update, ask the agent to pull upstream: it fetches, merges (resolving conflicts in your favor), then builds, restarts, verifies, and pushes to your fork — and the badge clears itself once you're no longer behind. The badge is a Discovery surface; hide it under Settings → Discovery and still pull whenever you ask.
What a self-edit can touch
From a single word to a whole new page — the agent edits the underlying source for each.
Notifications
Web push pings you when a turn finishes or the agent needs your input — even with the app closed. It pairs well with longer-running background tasks. Notifications are enabled per device, so turn them on once on each phone, tablet, or computer.
- Open Settings → Notifications.
- Use the enable toggle to turn notifications on for this device.
- When the browser asks for permission, choose Allow.
iPhone / iPad: web push only works from an installed Home Screen app, and alerts are tied to the exact address you install from — install from your own workspace subdomain, not the marketing site. In Safari, open Cial at your workspace address → Share → Add to Home Screen, then launch from the new icon and enable notifications inside it. On iOS the permission prompt must come from a tap, so use the enable toggle to trigger it; if nothing appears, tap again.
To stop alerts on a device, turn the toggle off under Settings → Notifications.
Account & billing
Your account lives at cial.dev — sign in, open your instance, and manage your plan. The dashboard has Profile (account details), Instances (open + manage), Billing (plan, trial, subscription), and Support.
Plans
Both plans run one private instance and your work stays yours on either.
New signups start on a 7-day Solo trial (no card required). When it ends, you continue on Solo if subscribed, or move to Free automatically — you're never locked out, and everything you created stays in place.
Opening, stopping, paying
Open your instance from the Instances area; a brand-new one runs first-run setup before the main app, and an asleep instance wakes on open (give it a moment; your conversations and settings persist). To stop, just close the app or sign out from the user footer — nothing special needed.
Manage your plan from Billing: see your current plan and trial countdown (also shown as a small badge in your in-app profile — informational only, changes happen on the dashboard). To upgrade, choose Solo, pick monthly or annual, and complete checkout. To change your card, switch billing cadence, or cancel, use Manage (a secure billing portal). Cancelling drops you to Free when the paid period ends — your instance and data remain.
Anything off with your plan, payment, or instance — reach out via Support on the dashboard.