AionUi

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.