SafetyCard Request a review

AionUi

Electron desktop and WebUI 'cowork' app that wraps CLI coding agents (Claude Code, Gemini, Codex and others via ACP) and a built-in agent, with MCP, skills, scheduled tasks, teams and chat channels.

github.com/iofficeai/aionui · 2026-10-04 · 6744099

Defense-in-depth score

1.5 / 10

AionUi is the desktop front end and launcher. The agent runtime, including tool execution and enforcement of approvals, lives in the separate AionCore backend, which was not reviewed, so most controls cannot be credited here. What this repo does ship is risky: the backend and MCP servers inherit the user's full environment with no sandbox; a browser tool, on by default, runs an npm package fetched by npx inside a browser that keeps the user's sign-ins; chat output rendering is not locked down; and scheduled tasks always run in YOLO mode. The approval card does show the exact command, and the browser bridge is carefully limited to one webview.

Safest setup

AionUi shows the exact command or raw tool input on each approval card, and its browser bridge drives only the side-panel webview. Beyond that this repository ships few controls of its own: agents and MCP servers run unsandboxed with your full environment, the browser tool is on by default, and scheduled tasks skip approval. The safest setup narrows what the app inherits and builds the containment around it yourself.

SetupHowWhat it gives you
A scrubbed environmentLaunch AionUi from a shell that holds only the model keys this work needs, each scoped where the provider allowsAgents and MCP servers inherit only the credentials you chose, not everything in your shell C1
Browser tool on demandSwitch off the built-in aionui-browser MCP server in the MCP settings and turn it on only for tasks that browseAgents read no web pages and fetch no browser package unless a task calls for it C3
Few browser sign-insKeep the in-app browser signed in only to the sites a task needs, and sign out afterwardsThe browser tool acts only in accounts you chose for this work C1
An approving mode per chatWhen starting each chat, pick a permission mode that asks before tool calls, since a new chat can reuse the last modeA person sees each command before it runs C2
Rules and skills you've readAdd only assistant rules and skills whose text you have read, and review the list from time to timeWhat steers later sessions comes from you C6
Its own VM or accountRun AionUi in a VM or separate OS user account holding only the project's files, with outbound network limited to the hosts you useAn outer boundary around agent-run code, which otherwise runs with your own access C4
Provider spending limitsSet a spending limit on each model provider account, and stop runaway work from the conversation's stop controlRunaway runs end at a ceiling you set C10

Approving with confidence

  • Read each prompt and approve calls one at a time; the card shows the exact command or raw input, while its title is written by the agent.
  • Scheduled tasks always run in auto-approve mode, so schedule only work you would let run unattended.

Handling data

  • Release builds upload the last day's log files to Sentry once a day, with no setting to turn it off; keep long-lived secrets out of prompts and the environment.
  • Conversation records, tool calls included, sit in the app data directory that agent tools can reach; copy them elsewhere if you need a lasting record.

Key gaps (2)

  1. Agent backend and MCP processes run unsandboxed as the user with the full inherited environment, so executed code is host-equivalent and holds every credential in the environment. C4 · Code-execution isolation
  2. The default-on browser MCP runs `npx -y chrome-devtools-mcp@0.16.0` without consent or an integrity check and gives the downloaded code the full inherited environment. C7 · Third-party extensions

Criteria

C1 Identity & least privilege

0.05 / 1.00

AionUi hands the agent backend the user's whole environment: the backend process is spawned with every parent environment variable (cloud keys, tokens, anything in the shell), and the built-in browser tool runs in an in-app browser whose sign-in cookies are shared across tabs and kept between sessions. Nothing in this repository narrows that authority, scopes credentials per tool, or checks authorization per request; whatever per-request checks exist live in the separate AionCore backend, which was not reviewed. A hijacked agent therefore acts with the user's local authority plus any websites they signed into inside the app.

C2 Approval gates

0.33 / 1.00

When an agent asks for permission, AionUi's approval card shows the exact command, or the raw tool input as JSON, along with the option buttons the agent offered. That is a good way to show the request. But the decision about which actions need approval, and whether the answer is enforced, belongs to the AionCore backend and the wrapped agent CLIs, which this repo does not contain. Scheduled tasks are always created in the agent's YOLO (auto-approve) mode, so background runs skip approval entirely, and a new chat can start in whatever permission mode was used last.

C3 Tool & action scoping

0.20 / 1.00

The one tool this repo ships and turns on by default is the in-app browser MCP (chrome-devtools-mcp). Its connection is carefully limited: the bridge listens only on localhost, needs a random token, and attaches only to the side-panel webview, never the main window. Inside that page, though, the agent can navigate to any URL, click, type and run scripts in a browser that holds the user's sign-in cookies. Every other tool lives in AionCore and the wrapped CLIs and was not reviewed.

C4 Code-execution isolation

0.00 / 1.00

AionUi contains no isolation layer of its own. The backend that runs agents, and the MCP servers it launches, start as ordinary processes running as the user, with the full inherited environment. Some wrapped CLIs have their own sandbox modes (the UI has labels such as 'yoloNoSandbox' and Codex 'sandboxMode' settings), but those belong to third-party agents and are not enforced here. If agent-run code goes wrong, it has host-level access, including every credential in the environment.

C5 Untrusted input blast radius

0.05 / 1.00

Out of the box the agent has a browser tool that reads arbitrary web pages, which is untrusted content, inside a browser that keeps the user's sign-ins. Nothing in this repo tracks untrusted content or restricts what the agent may do after reading it. The chat and preview renderers are not locked down. Whether irreversible actions are approved depends on the backend and the agent CLIs, which were not reviewed.

C6 Memory, context & configuration integrity

0.10 / 1.00

Conversations, assistant rules, imported skills and scheduled-task skills are all stored by the AionCore backend, and the client offers endpoints to write assistant rules, import skills and turn on a skills market. This repo has no validation, provenance tagging or review step for anything persisted and later loaded into agent context. Workspace instruction files are loaded by the wrapped CLIs themselves. Persisted rules and skills carry over into the user's later sessions and can steer tool use.

C7 Third-party extensions

0.20 / 1.00

On first use, the default-on browser tool runs `npx -y chrome-devtools-mcp@0.16.0`. That downloads and runs an npm package without asking the user. The version is pinned, but there is no hash check and its dependencies are not locked. A second built-in entry (off by default) uses `@latest`, and MCP servers the user adds are not pinned or verified by this repo. The launcher passes its whole environment to the downloaded server, so a compromised package would get every credential the app inherited.

C8 Secrets & sensitive-data protection

0.20 / 1.00

Release builds have a Sentry key built in, and once a day, starting 30 seconds after launch, the app uploads the last day's frontend and backend log files to Sentry as a gzipped attachment. There is no opt-in, and no redaction applies to those files. Redaction (tokens, emails, home-directory names) exists only for one path: error summaries attached to telemetry. The backend and MCP servers also receive the full environment, so long-lived keys in the shell reach every agent process.

C9 Audit & traceability

0.38 / 1.00

Agent tool calls and permission requests are stored as typed conversation messages ('acp_tool_call', 'acp_permission') and fetched from the backend's conversation API, so a local transcript exists. Writing and storing that record happens in AionCore, which was not reviewed, so its completeness, its attribution of who approved what, and its durability cannot be shown here. The record lives in the app's own data directory, which the agent's own unsandboxed tools can reach.

C10 Limits & kill switch

0.00 / 1.00

This repo sets no step, time or cost limit on agent runs. The only hit is an optional 'maxTurns' field with no default. There is a working stop: the UI can cancel a conversation or a team run, and on shutdown the app kills registered agent process groups (SIGTERM, then SIGKILL). Scheduled tasks keep firing on their own schedule, and runaway work is not bounded except by the provider account.