SLICC Browser-Native Agent
Operate browsers, shells, files, and authenticated apps from one agent workspace.
- Source repo
- ai-ecoverse/slicc
- Stars
- ★ 32
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 77/100 · Good
At a glance
- Works with
- Universal · cross-platformClaude API
- You'll need
- Typical use
- A developer who works across browsers and terminals can edit files, run tools, and verify application behavior without leaving one workspace.
- Main limitation
- The project is explicitly an active prototype, and its intended audience is expected to tolerate occasional breakage.
- Source review
- 77/100 · Good
What does this agent do, and when should you use it?
SLICC, short for Self-Licking Ice Cream Cone, is an agent runtime that lives inside a browser and can control that browser. It combines a virtual filesystem, a practical shell, Playwright-based browser automation, generated interfaces, and multi-agent delegation in one workspace for development and authenticated web tasks. Users can enter through the hosted web app, macOS application, Node.js CLI, Chrome extension, or headless follower CLI; the same core also spans Electron, an iOS follower, GitHub Actions, and cloud execution. A primary agent called a Cone can delegate work to Scoops with isolated sandboxes, shells, and conversation histories, then collect their results. The repository describes the product as an active working prototype: the macOS app is currently the easiest entry point, while native Windows and Linux graphical interfaces are not yet available.
After a user gives a Cone a task, SLICC can read and edit workspace or mounted files, run commands such as bash, git, node, python, grep, and playwright, inspect pages, control tabs, capture screenshots, and act in authenticated browser applications. It can connect additional browser windows into a Tray, attach to Electron applications, and embed a follower in third-party pages through @ai-ecoverse/cherry. A Cone can spawn isolated Scoops to perform subtasks in parallel; their results, durable error cards, file links, images, and generated interfaces return to the chat workspace. mount --source exposes S3, Cloudflare R2, MinIO, da.live, and AEM Source Bus content through the VFS, while serve --bridge and serve --ttl 30d publish live driveable previews or time-limited immutable snapshots. Before conversation compaction, SLICC stores the full transcript under /sessions; the optional Memory v2 gelatiere can review archived sessions and suggest skills or workflows.
- A developer who works across browsers and terminals can edit files, run tools, and verify application behavior without leaving one workspace.
- An operations user can automate repetitive steps in an already authenticated web application using page inspection, screenshots, storage access, and scripted tab control.
- A technical power user can split a large research, implementation, or validation job across isolated Scoops and have the Cone coordinate the findings.
- A user away from the main machine can join the same Tray from another browser, the iPhone or iPad follower, or the Go
sliccCLI. - A CI team can run a leader on a GitHub Actions runner, mount a repository, submit a prompt, and retrieve the generated file within a workflow.
- A content or engineering team can expose local folders and supported S3-compatible or Adobe content stores through a common virtual filesystem.
How do you install or deploy this agent?
The fastest local path requires Node.js 22 or later and Google Chrome: run npx sliccy, then configure an LLM provider in the first-run settings dialog. For a global installation, run npm install -g sliccy followed by slicc. To develop from source, run git clone https://github.com/ai-ecoverse/slicc.git, cd slicc, npm install, and npm run dev; this starts the Node server with Vite HMR and opens http://localhost:5710. macOS users can alternatively download the latest .dmg from the repository releases. Install the headless follower with npx sliccy --install-cli; native Windows also supports irm https://www.sliccy.ai/install-cli.ps1 | iex.
How do you use this agent?
Start with npx sliccy, choose and configure a supported model provider during first-run setup, and describe a task in the workspace composer. The agent can then use its shell, VFS, and the current browser session. To expose a host folder, mount it at an empty path, for example npx slicc --mount=~/Projects/foo:/mnt/foo; remove it with umount /mnt/foo. To add another browser, choose “Enable multi-browser sync” from the avatar menu, copy the sync URL, and use “Connect to another browser” in the second browser. For Electron, use a command such as npm run dev:electron -- /Applications/Slack.app. After configuring server-side credentials, a remote store can be mounted with a command such as mount --source s3://my-bucket --profile r2 /mnt/r2.
What are this agent's strengths and limitations?
- The agent loop, VFS, shell, UI, and tools run primarily in the browser and can act on the same browser hosting the workspace.
- One core supports hosted web, CLI, Chrome extension, Electron, macOS and iOS followers, GitHub Actions, and cloud-oriented execution paths.
- The Cone/Scoop model provides parallel delegation with separate sandboxes and contexts instead of forcing every task into one conversation.
- Its working environment includes practical command-line tools plus local and remote mounts for S3, R2, MinIO, da.live, and AEM sources.
- Domain-scoped secret injection keeps real credential values hidden from the agent.
- The project is explicitly an active prototype, and its intended audience is expected to tolerate occasional breakage.
- The local CLI requires Node.js 22 or later and Chrome; no native Windows or Linux graphical interface is currently available.
- Users must supply and configure model-provider credentials or allowances, and several listed providers are described as unverified YMMV options.
- The Chrome extension is a thin CDP bridge that loads the hosted leader application rather than a self-contained bundled agent UI.
serve --bridgecarries a documented cross-subdomain cookie risk: cookies set forDomain=.sliccy.noware readable across previews.
How does this agent compare with similar options?
The repository positions SLICC in the OpenClaw-alternative space and credits OpenClaw, NanoClaw, and Pi as inspirations; Pi is described as the core inside every SLICC instance. SLICC's stated distinction is that the agent runtime lives in and controls the browser, while combining a shell, VFS, multi-browser Trays, Electron attachment, and delegated Scoops in the same workspace.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| SLICC Browser-Native Agent This agent | 77 · Good | ★ 32 | today | TypeScript | Claude API |
| Rakazo AI Teammates | 63 · Some gaps | ★ 2.9k | today | TypeScript | — |
| Octop Self-Hosted Assistant | 67 · Some gaps | ★ 4.8k | today | Python | Codex · Claude Code · OpenAI API |
| Orbital Project Agent | 65 · Some gaps | ★ 290 | 4d ago | Python | Codex · Claude Code · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The README, tests, and workflows show capability gates, bounded filesystem behavior, user approvals, explicit mounts, preview revocation, sync-link reset, and scoped GitHub permissions; credentials are described as remaining server-side, and third-party Actions are commit-pinned. Deductions apply because the product can still control authenticated browsers, run a near-real shell, remount host directories automatically, and publish persistent previews. Several security properties are documentary assertions without the referenced secrets documentation or implementation, and confirmation or rollback is not demonstrated uniformly for every external action. Repository, package, and Apache copyright attribution are present, but publisher identity is unverified and detailed contributor provenance is absent.
The README, package metadata, and tests describe a reasonably coherent product with pinned direct dependencies, runtime requirements, extensive checks, explicit unsupported-operation errors, and concurrent-edit conflict handling. Durable failure cards and loss-avoiding compaction behavior provide strong evidence for failure messaging. Deductions reflect the absence of a lockfile, CI results, or dependency-availability evidence in the supplied material, plus the broader README claim of Node 22+ versus the precise >=22.18.0 package requirement. Hosted services, model providers, and numerous platform components remain statically unverified availability dependencies.
The intended users and browser, terminal, authenticated-app, development, and automation scenarios are described in unusual detail. macOS, iOS, CLI, extension, Electron, cloud, and headless paths provide strong environment coverage. Cherry capabilities and feature flags, mounts, opt-in previews, and unsupported-method tests establish useful boundaries. Deductions apply because Cherry features default to enabled and there is no single auditable policy for agent triggering and approval across all actions; missing Windows/Linux UI, prototype status, and experimental features also limit boundary completeness.
The README has strong information architecture, several installation paths, extensive task examples, and platform-specific guidance. The full Apache-2.0 license is present, package versioning is explicit, and SECURITY.md identifies a private reporting route and supported scope. Deductions reflect potentially confusing coexistence of SLICC, slicc, sliccy, sliccy.com, and sliccy.ai; no changelog or revision-to-release mapping is supplied; limitations are disclosed but not collected systematically; and maintenance ownership is represented mainly by an unverified organization account and an unspecified “we,” without named responsibility or service commitments.
File and diff previews, session recovery, browser control, storage mounts, parallel agents, and driveable previews produce directly actionable outputs and offer substantial incremental value over a text-only agent. The deduction is for an intrinsically complex system spanning hosted infrastructure, model calls, browser control, and many runtimes, while the supplied material does not quantify provider expense, resource use, latency, or operational risk; the cost-benefit case is persuasive but incomplete.
Core claims can be traced to detailed README behavior descriptions, package scripts and versions, and Cherry tests covering capability denial, errors, and feature negotiation. License and security-maintenance claims receive some cross-file support. Deductions apply because many product and security claims appear only in the README, the supplied tests cover a narrow Cherry surface, and no implementation, release record, or independent material corroborates most capabilities. Promotional and factual language are generally distinguishable, but experimental status, inference, and guarantees are not systematically labeled.
- This is a low-confidence static review; no code, tests, installer, extension, or hosted service was executed.
- The agent can operate authenticated browsers, execute shell commands, and read or write explicitly or automatically mounted directories. Use least-privileged browser profiles, dedicated accounts, and narrowly scoped mounts.
- The curl-to-shell and PowerShell-iex installers, hosted leader, persistent previews, and cross-browser synchronization expand supply-chain and data-exposure risk. Pin releases and separately review installers, domain boundaries, and revocation behavior before deployment.
- The README explicitly accepts a cross-subdomain Domain-cookie risk on *.sliccy.now; do not place sensitive cookies readable across that domain scope.
- Credential isolation, prompt-injection trust boundaries, and domain scoping depend substantially on docs/secrets.md and implementation not included in the evidence, so they are not verified here.
FAQ
Does SLICC require a paid account?
What local access does it receive?
Can it run on Windows or Linux?
What happens when a provider fails or runs out of quota?
Can the agent read stored credentials?
~/.slicc/secrets.env for the CLI or chrome.storage.local for the extension.