# Introducing CoreSpeed TIE (/blog/introducing-corespeed-tie) CoreSpeed TIE lends your agents your computer. Until now, every agent got one of two kinds of computer. A desktop agent, like Claude Code or Codex on your laptop, worked on the machine it ran on, and only that one. Meanwhile, a cloud agent got a new machine in a sandbox, and a new machine starts empty. Before it could do your work, you had to rebuild your computer inside it: install your apps, copy over your files, and sign it in to everything again. **TIE** ends that trade. Any agent, anywhere, can work on your computer the way you do: in your terminal and files, your signed-in browser, your desktop apps and your local MCP servers. Run one command on a Mac, and every call still goes through your rules. ## A day with TIE \[#a-day-with-tie] On the train in, you ask an agent in the cloud to fix the flaky test that broke last night's build. It runs `npm test` in the checkout on the Mac mini at the office, finds the race, and gets the fix ready to push with the `gh` you're already signed in to. Your rules say pushes wait for you, so Slack pings your phone, and you approve it before your stop. At your desk, Claude Code pulls last month's numbers from the Stripe dashboard open in your Chrome. Nobody pasted an API key; the tab was already signed in. During your one o'clock, an agent rebuilds the quarterly deck in Keynote on your Mac with its own cursor. Yours is still in the meeting notes where you left it. At night, a build agent works through its queue on the office Mac minis it owns. The activity log shows what ran on which machine, and who approved each step. ## One command, one outbound link \[#one-command-one-outbound-link] You tie a machine to your CoreSpeed organization with one command: ```bash npx @corespeed/cs tie ``` You sign in and pick a folder your agents may work in. A small daemon, `tied`, opens one outbound link to CoreSpeed, so your router, firewall and VPN stay as they are. The machine's tools show up on CoreSpeed's MCP server next to Gmail, Slack and Linear, named like `device__hao-s-macbook__shell_run`, so any agent that connects to CoreSpeed can call them. A tied machine can share four things, each with its own switch: * **Shell and files.** File reads and writes stay inside the folder you chose. Commands start there and run as you, so your signed-in CLIs, like `gh`, `aws` and `ssh`, come with them, and every command is checked against your Smart Approval rules before it runs. * **Your browser.** Agents use the Chrome or Edge you already use, signed in to everything you're signed in to. Nothing is copied to a cloud browser. * **Your screen.** Desktop apps with no API, like Keynote, Excel or Final Cut, driven through the accessibility tree. The agent gets its own cursor, so yours stays put. * **Local MCP servers.** DaVinci Resolve, Xcode, a local database: if it speaks MCP on your machine, your agents can reach it. Browser and screen are built on the open-source Cua Driver. The switches live on the machine, and CoreSpeed can't turn on anything you've turned off. Your logins, cookies and keys stay on your machine, and so does the credential that opens the link. ## Every call goes through your rules \[#every-call-goes-through-your-rules] A tied machine is a connection like any other, so every call passes [Smart Approval](/blog/introducing-smart-approval). Reads run. Writes are judged against the rules you wrote. The ones your rules name wait for you, in Slack, by email, on the dashboard, or, with [TIE for Mac](https://assets.corespeed.io/releases/tie-mac/latest/Tie.zip), as a macOS notification with **Approve** and **Deny**. The rest of your desktop isn't interrupted, and the activity log records which agent used which machine, for what, and who approved it. The Mac keeps the last word. Commands like `sudo` and paths like `~/.ssh` are on a list in the machine's own `tie.json`, and they're refused there even after an approval. ## One machine, many agents. One agent, many machines. \[#one-machine-many-agents-one-agent-many-machines] A tied machine starts out private. You can share it with your organization when you tie it or later, and then every teammate's agent can use it under the same rules. A machine can also belong to an agent instead of a person. The office Mac mini your agents build and test on is nobody's laptop. You tie it with the agent's key, and whoever manages that agent manages the machine. Tie a few of them, and one agent can work across all of them. ## We built the obvious version first \[#we-built-the-obvious-version-first] The obvious way to let an agent use a signed-in app is to have the app publish its own tools. That's the idea behind WebMCP, the draft standard Chrome is trialing: a page declares its actions, and an agent calls them. We built exactly that in September. Our admin cockpit, where an agent marks a connector beta or GA, published its actions through WebMCP. Our Mac app opened it on Benji's machine and relayed the tools to agents in our cloud sandboxes as two MCP calls, `bridge_list_tools` and `bridge_call`. His session never left the Mac, and every write waited for his click. It worked, and it showed us where the obvious design stops. It reaches only the pages that publish tools, while real work runs through terminals, signed-in browsers, desktop apps with no API and local MCP servers. It belonged to one agent platform. And its gate was a dialog on one screen, so the work stopped whenever that screen did. TIE keeps what worked, the session that never leaves your machine, and drops the three limits. On October 15 we deleted the bridge, and our connector rollouts now run through TIE on Benji's Mac. A bridge is something you cross. A tie holds two things together, and comes undone with `cs untie`. ## What will you tie? \[#what-will-you-tie] We built TIE to get our own agents past one login screen. The bigger idea is that the computers people already own are the best-equipped places an agent will ever work: years of installed apps, signed-in accounts, files, licenses and the hardware plugged into them. Until now, all of that stayed out of an agent's reach. The uses in this post are the ones we could picture. A studio Mac running Logic, a lab machine with an instrument on its USB port, a rack of Mac minis testing an app on every OS version: the ones we haven't pictured are why TIE ships as a beta, and we hope it helps with yours. When you find a use we didn't expect, tell us. TIE is the newest part of CoreSpeed, which gives your agents their apps, memory, rules and now your computers, through one MCP server. Everything your agents need. ## Questions \[#questions] **Which agents work with TIE?** Any agent that connects to CoreSpeed's MCP server: Claude Code, Codex, Cursor, Gemini CLI, or one you built with an SDK. **Do my passwords or cookies leave my machine?** No. Browser tools drive your own Chrome or Edge on the machine, and your logins, cookies and keys stay there, along with the credential that opens the link. **What can an agent do without asking me?** Reads run. Everything else is checked against your Smart Approval rules, and the calls they name wait for you. The machine's own list in `tie.json` has the last word after that. **How do I stop it?** Pause the machine from TIE for Mac, switch a provider off on the machine, or run `cs untie` to remove it. ## Get started \[#get-started] TIE is in beta. It runs on macOS today, with Linux and Windows next. Run `npx @corespeed/cs tie` on the machine you want to lend, or download [TIE for Mac](https://assets.corespeed.io/releases/tie-mac/latest/Tie.zip) (macOS 14 or later, with Node 22 or later), the menu bar app that ties the machine, brings approvals as notifications and keeps itself up to date. Then point any agent at CoreSpeed's MCP server. The [cs tie docs](/docs/cli/tie) cover sharing, agent-owned machines and the provider switches.