Updated 10 hours ago
CoreSpeed TIE beta connects agents to a Mac’s local tools and signed-in apps

CoreSpeed TIE beta connects agents to a Mac’s local tools and signed-in apps

CoreSpeed’s October 23 TIE beta exposes selected Mac capabilities through its MCP server. Local switches, Smart Approval rules and a machine denylist govern different parts of access.

A macOS beta using the computer already set up

CoreSpeed introduced TIE on October 23 as a way for agents connected to its MCP server to use an existing Mac. The company describes access to local files and shell commands, a signed‑in browser, desktop applications and local MCP servers, instead of setting up a separate cloud computer with those resources.

TIE is in beta on macOS. The TIE for Mac menu‑bar app requires macOS 14 or later and Node 22 or later, according to the post. Linux and Windows are described as next, without a release date. OpenTools has not installed the daemon or tested an agent connection.

Four capabilities, each with a local switch

The [release describes four separately switched capabilities](https://corespeed.io/blog/introducing‑corespeed‑tie): shell and files, browser, screen, and local MCP servers. A user signs in and selects a working folder. CoreSpeed says file reads and writes stay within that folder, while commands start there and run as the user, including access through already signed‑in command‑line tools. That distinction matters: the chosen working directory should not be mistaken for a claim that every shell command runs in an isolated sandbox. Browser tools use the machine’s existing Chrome or Edge session. Screen control uses the accessibility tree for desktop applications, and local MCP servers expose their own tools. CoreSpeed says the switches reside on the machine and that it cannot enable a capability the user has turned off. Those are issuer‑described controls, rather than independently verified security guarantees.

Approval rules and the machine denylist are separate gates

Under CoreSpeed’s Smart Approval description, reads run, while writes are assessed against the user’s rules. Calls named by those rules wait for approval through the supported notification surfaces. This is a configurable policy model; it does not mean every action needs a new human click.

The machine also maintains a denylist in tie.json. The post gives sudo and ~/.ssh as examples of commands or paths refused locally even after approval. For someone considering the beta, the useful review is therefore threefold: which capabilities are enabled, which operations the approval rules allow or hold, and which operations the machine rejects altogether. The post also describes pausing the machine, switching a provider off or removing its tie as ways to stop access.

AI‑generated conceptual illustration by OpenTools Team: a desktop computer and physical switches represent locally selected capabilities and access decisions. This is illustrative artwork, not an actual CoreSpeed interface, installation or tested security result.

Share this article

PostShare

Related News