This page describes manual pairing with YOLO off unless stated otherwise. Start the connection as described in setup, then review its request in Settings > Agent control > Sessions.
A connection receives a grant
Section titled “A connection receives a grant”Approve one project, its selected existing workspaces and the permissions needed for the task. Sharing a project folder does not automatically share all its workspaces, Android devices or Chat history. Explicitly check additional workspaces; select devices, permitted Android packages, browser origins and individual Chat conversations when those features are needed.
The grant is tied to the authenticated connection. It ends on revoke, disconnect, app/server restart or invalidation of the workbench UI registration. Client names do not carry permissions. lomi_connect selects an already approved workspace and returns retry identity; it does not grant another workspace.
New workspaces created through the authorized connection become available to their creator. A new project needs its own exact-folder approval, with at most 16 approved project roots per connection. Closing a project requires access to all its current workspaces as well as explicit close permissions.
Permission families
Section titled “Permission families”The UI groups related scopes into task-oriented switches. Some actions require several families together; the tool’s live description and reference are authoritative for a particular target.
| Scope family | Grants | Additional boundary |
|---|---|---|
workspace.read, workspace.write, workspace.close |
Read authorized layouts; create/rename/select; request closure. | Closure applies existing dirty-file guards and resource ownership checks. |
project.open, project.close |
Request another root or close an exact project. | Each new root needs approval; closing requires every current workspace. |
panel.create, panel.focus, panel.close, panel.move |
Create, select, close or arrange supported panels. | These do not independently authorize shell/device startup or resource input. |
terminal.execute, terminal.read |
Create/control/execute and read owned terminals. | Exactly one approved Bash/Zsh profile and its revision; input requires the current lease. |
files.read |
List, search and read approved project disk files. | Project-relative paths, pinned roots and secret/link/special-file exclusions. |
files.mutate, files.create, files.rename, files.trash |
The allowed file creation, rename/move or Trash action. | Parent/entry revisions; no overwrite; Trash has durable recovery staging. |
editor.read, editor.write |
Read unsaved loaded buffers and apply edits. | Saving also needs file-mutation access; buffer and disk revisions are distinct. |
artifact.import, artifact.import_file, artifact.export |
Import APKs, import opaque files or export owned bytes to a new project file. | Exact length/hash and original source access; import is not installation. |
browser.navigate, browser.read, browser.interact |
Open/navigate, observe and interact. | Exact allowed scheme/host/port; isolated profile, ownership, generation and lease. |
browser.capture_composite, browser.download, browser.upload |
Composite screenshots, same-origin downloads or file attachment requests. | Capture can include third-party frames; uploads need exact-file/destination approval. |
android.read, android.control, android.interact, android.observe, android.capture |
Shared device status, start/stop, input, UI projection and PNGs. | Exact device/generation; input needs a lease and a focused visible selected panel. |
android.launch, android.logs, android.install |
Approved package launch/logs or APK installation request. | Package allowlist; APK installation approves an immutable copy and exact device. |
android.setup, android.manage |
SDK planning/install/recovery or device management. | Exact native plans, provider terms and protected destructive-action decisions. |
git.read |
Guarded repository observations. | Also needs file reads; does not allow Git hooks, helpers or network. |
git.write, git.execute, git.network, git.push, git.pull, git.discard |
The corresponding Git mutation and configured code/network use. | Concrete native approval; push/pull/discard have additional scopes. |
chat.read, chat.open, chat.create, chat.draft, chat.export, chat.stop, chat.send |
The chosen conversation workflow. | Exact shared conversations; sends approve context, model and possible charges. |
settings.open, settings.read, settings.write |
Open a section, read nonsecret preferences or request supported changes. | Application-global settings, anchored to a live approved workspace. |
Permission and approval are different
Section titled “Permission and approval are different”A granted scope allows the agent to request the operation. With YOLO off, some effects still require a concrete decision:
- Settings: terminal input claims, new project folders, settings changes, browser uploads, Android setup/device actions and APK installs.
- Main window: Git mutation plans and Chat sends; existing Save/Discard/Cancel guards for dirty files during closure or Trash.
- MCP client: any additional approval required by that host’s tool policy.
awaiting_user means an operation is waiting, not completed. An agent cannot approve by placing approve: true in its arguments. Decisions bind the exact operation, target, content/revisions and expiry. A changed plan requires a fresh review.
Reading a file does not authorize editing its buffer. Editing a buffer does not save it. Importing an APK does not install it. Opening an Android panel does not start its emulator. Reading Chat does not send a provider request.
Ownership and human takeover
Section titled “Ownership and human takeover”A panel ID identifies a view. A terminal session/device/browser generation identifies its current runtime. A lease authorizes input for that runtime. These values are not interchangeable.
An existing human terminal is not automatically agent-owned. Claiming it through lomi_panel_control needs approval and does not restart the shell. The terminal that launched the agent is a protected origin. Human input invalidates terminal control; browser takeover invalidates its control and old observations. Android blur/takeover releases held keys and touches.
Focus/rearrangement cannot silently start a lazy terminal or emulator. Transferring an authorized live panel can preserve its PTY, stream, buffer or device; it does not transfer access to an unapproved workspace.
What reaches the model
Section titled “What reaches the model”Tool results can include project text, loaded editor text, page content, screenshots, Git metadata and explicitly shared Chat text. An external client’s provider can receive those results as model context. Local MCP transport does not mean the model runs locally.
Known secret filenames are excluded by file tools, and credentials/system prompts/provider metadata are excluded from general Chat/settings reads. These exclusions do not guarantee that ordinary source files, logs, screenshots or shell output contain no sensitive data. Treat page text, logs, terminal escape sequences and other tool observations as untrusted data, not new instructions.
Terminal shells and approved Git execution use your host account. Browser profiles isolate stored web data; origins are not an egress firewall. Permissions describe Lomi’s tools, not an OS sandbox.
YOLO mode
Section titled “YOLO mode”Preferences > Automatically approve requests (YOLO) saves a global policy that automatically pairs local clients and authorizes supported operations in every workspace, including new workspaces. It removes the manual workspace/device/conversation selection boundary for valid supported resources and automatically approves supported effect plans.
The reviewed implementation also routes Android management through automatic decisions, supplying the prepared license digests and required destructive confirmation. Do not assume Android’s normal per-request dialogs still protect you in YOLO. Chat sends can incur charges, and approved Git hooks/helpers can execute code.
The enable dialog describes this broad access. YOLO defaults to off and is independent of automatic server startup. Changing it revokes active sessions and pending authority; reconnect. Turning it off restores manual pairing. YOLO has a bounded 500-project grant budget rather than the manual 16-root budget. Resource identity, revision/hash checks, closed schemas, limits, ownership rules and unsaved-file guards still apply. Your client’s own tool policy remains separate.
End access
Section titled “End access”Disconnect the client to end its connection, use Stop all sessions under Stop all access in the sessions view, or select Turn off server in the page header. A native Lomi menu stop remains available when the workbench is unresponsive.
Revocation invalidates authority and cached results; it does not assert that commands already dispatched have exited or that writes have been undone. Inspect actual terminal/device/file state and the operation receipt before taking further action.
Source: pairing switches, grants and YOLO policy, Android automatic decisions.