Separate trust boundaries
A provider runs an agent. An application connection exposes a separately approved outside application. A remote-workspace connection transports an authenticated projection. None implies either of the others.
Provider integration status
| Provider | Current AEXGrid path |
|---|---|
| Codex | Structured app-server sessions: model discovery, start/resume, streaming, approvals, questions, interruption, and native Workbench tools. |
| Kiro CLI | Structured ACP v1 sessions with a session-scoped MCP bridge; installed handshake verified in the development environment. |
| OpenCode | Structured ACP integration with provider-owned authentication/state profiles and configuration controls. |
| Cursor | Structured ACP adapter and account/API-key configuration; an installed CLI handshake was unavailable for recorded verification. |
| Claude Code | Interactive PTY terminal provider; terminal output is not presented as structured activity or managed coordination. |
Discovery, installation, and profiles
AEXGrid scans PATH and common user locations. Supported managed npm packages install into AEXGrid’s data directory with a reusable cache; the app does not perform a global npm install or rewrite the system PATH.
Provider credentials remain provider-owned. Supported profiles isolate provider state where the provider permits it. Saved literal command arguments are plaintext and must not contain secrets.
Application connections
Application connections are workspace-owned and owner-approved. A packaged sidecar and Agent Runner expose exact advertised actions; grants, revisions, idempotency receipts, bounded observations, and per-agent authorization are enforced by the desktop runtime.
No third-party application is universally enabled by this page. A connection must be installed, configured, opened, and granted before actions are available to an agent.
Remote dashboard and direct connections
The dashboard signs in, discovers account-bound available workspaces, and establishes a protected connection with the desktop host. Connection setup and admission are separate from the workspace session itself.
The remote projection is bounded and allowlisted; it is not arbitrary remote desktop access. Desktop availability, device identity, protocol compatibility, and network traversal affect whether a workspace opens.