Automating your Mac

OOMU can read and write files, drive Apple apps, control applications, operate a contained browser, and act on the screen. Every one of those powers is a named capability with a fixed shape, and every one of them is governed by macOS rather than by a permission layer OOMU built for itself.

If macOS has not granted the access, the action does not happen. There is no OOMU-side override.

---

Files

Six capabilities cover the filesystem:

There is no OOMU file sandbox. macOS Files and Folders access is the boundary, exactly as it is for any other application, and you see its state in Settings → Mac access.

What OOMU does add is identity binding. Before acting, it resolves the real path (symlinks are rejected outright) and records the file's device, inode, byte length, and modification time. That identity travels with the action. If the file changed between the moment OOMU looked and the moment it acted, the action fails rather than operating on something that is no longer what it read.

Note the difference between the last two rows. files.trash is marked reversible; files.delete_permanently is marked irreversible and carries that classification through to its receipt.

Reversible means reversible. files.trash calls the same macOS file-manager routine Finder does, so the file lands in your actual Trash with Put Back available, and OOMU records the path it ended up at. It is not a move to a folder OOMU invented.

Files OOMU produces are opened the way macOS opens anything: through LaunchServices, in whatever application you have set as the default. OOMU does not bundle its own viewer or decide what should open a document on your behalf.

---

Apple apps

Mail, Calendar, Reminders, Notes, Contacts, Photos, and Music are driven through native macOS integration, not through a generic scripting escape hatch. Each action is its own capability with its own arguments: apple.mail.draft, apple.reminders.complete, apple.notes.update, and so on. See Connecting services for the full list.

Twenty-seven capabilities cover them, and the split matters: reading and writing are always separate. apple.mail.read cannot send anything. apple.contacts.lookup returns a bounded set of fields for a specific query rather than handing over your address book. apple.calendar.read goes through EventKit directly instead of scripting the Calendar app, and relative dates like tomorrow or next week resolve against your Mac's own clock and time zone before anything is read.

OOMU can also deliver a notification, read and set the clipboard, and list and run Apple Shortcuts you already have installed. It cannot create or modify a shortcut.

The first time OOMU touches one of these, macOS asks. That prompt is macOS's, in macOS's words, and your answer lives in System Settings.

When macOS says no

A refusal is not an error page. Whether it arrives as an EventKit authorization rejection or an AppleScript denial code, OOMU normalizes it to the same thing, and two things happen: the assistant explains in its own words what it was trying to do and could not, and OOMU adds the exact place to fix it.

OOMU needs permission to access your Calendar. Grant access in System Settings > Privacy & Security > Calendars.

OOMU needs permission to access Mail. Allow OOMU to control Mail in System Settings > Privacy & Security > Automation.

The raw operating-system error is never shown to you, and the guidance never replaces the explanation. Both messages exist in all twelve of OOMU's languages.

---

The menu bar

OOMU keeps a raven in your menu bar, drawn as a template image so it inverts correctly in light and dark mode like every other system item.

The count is the useful part. Long-running work does not require you to keep the window open to know whether anything is still going.

---

Controlling applications

Five capabilities operate applications by their native bundle identity:

Applications are addressed by bundle identifier, and the identifier is validated. Quit is a normal quit request, not a kill: an application with unsaved work gets to say so.

---

The browser

OOMU has a contained browser panel. When a task needs a live page, a Browser tab appears alongside the workspace tabs and you watch the page as OOMU works in it.

Nine capabilities govern it:

Observe comes first. Every action names an element from a snapshot OOMU actually took. There is no capability to evaluate arbitrary JavaScript in the page, and page content cannot reach OOMU's internal commands.

You can reload, resize, and close the browser panel at any time. Closing it ends the session.

Downloads. The browser panel has a downloads indicator, but in this beta the native download list is not yet populated, so no downloads are surfaced. Treat browser downloading as unavailable for now.

---

Screen actions

Eleven capabilities let OOMU work with on-screen interface elements through the macOS accessibility system:

The model is the same as the browser's, and the constraint is the important part: every action targets an element from a specific observation. OOMU records the observation identifier and the element's identity, and an action carrying a stale reference fails rather than clicking whatever now occupies that position.

This is what stops the classic screen-automation failure, where a dialog appears between looking and clicking and the click lands somewhere unintended.

These capabilities require macOS Accessibility access, and screenshots require Screen & System Audio Recording. Both appear in Settings → Mac access with their live state.

---

Web search

web.public.retrieve is how OOMU looks something up. Nothing is ever displayed. No browser window opens, nothing is shown to you, and you do not watch a page load. It runs in two stages, and the first one usually finishes the job.

Each stage gets a fixed slice of the overall deadline, agreed before either runs. If the first stage overruns, the second is skipped rather than allowed to push the turn past its budget.

One search either way. There is no research planner, no retry loop, and no crawling of the result pages. Responses are capped, redirects are bounded, and results are only accepted from the search host they were supposed to come from.

This is a different thing from the contained browser panel above, which is the only browser you ever see, and only when a task genuinely needs a live page.

The chat labels this Web research and lists the Sources it read.

If the first stage fails and no supported browser is installed for the second, the capability reports that plainly rather than silently returning nothing. If the search provider presents a verification challenge, OOMU stops and says so rather than trying to work around it.

Web search is blocked entirely by Air-Gap Mode.

---

How an action is classified

Every action OOMU takes produces an effect descriptor before it runs, and that descriptor is what gets recorded. It carries, among other fields:

Anything irreversible, above standard privilege, or involving executable content is flagged for isolated qualification. See Evidence & receipts.

---

Staying in control

While a turn is running, three controls sit in the composer:

An autonomous turn is also bounded: OOMU takes at most eight tool steps before it must return an answer. It cannot loop indefinitely on your machine.

Activity, a tab in the Chat workspace, shows everything in progress, everything that needs you, and everything that finished.

---

Related

• Working fast: the Quick Launcher, which reaches all of this from anywhere on your Mac.
• Connecting services: granting the access these capabilities need.
• Capability catalog: every capability identifier in one table.
• Privacy & security: why macOS governs this rather than OOMU.