A ticket, a branch and a pull request
Consider an issue-to-pull-request workflow using GitHub and Linear through remote MCP servers, with the apps the team already runs. Available tools depend on the servers and accounts you connect.
- Codex picks up the issue. On the build Mac mini, Codex calls the Linear connection through Toolstile to read the issue, its comments and the linked design notes. Toolstile checks the request against Codex's current access and forwards it with the approved Linear account.
- The work happens on the machine. Editing files, running tests and pushing a branch are the app's own work on the Mac mini. Toolstile is only in the path for calls that go through its MCP connections.
- Codex opens the pull request. It calls the GitHub connection to create the pull request, then uses the Linear comment tool to add the link to the issue. Those tools are allowed for this Codex connection.
- A blocked tool stays blocked. If Codex ever calls
delete_repository, Toolstile refuses it, because that tool is blocked for Codex on this connection. It does not appear in Codex's tool list either. - Claude Code on the CI runner has its own access. It is a separate authorization with a separate grant: it can comment on pull requests and read checks, and nothing else.
- Activity shows the trail. Each call is listed with the app, the connection, the tool, the outcome and the timing. Request arguments and results are not stored unless you turn on debug capture.
Tool names here are examples. Toolstile lists the real names your server exposes when you edit access, so you never have to guess them.
What changes for the team
- One address for every app. Codex, Claude Code, Cursor and Claude Desktop all point at Toolstile. Add a service once instead of configuring its MCP server in each app on each machine.
- Access that fits the job. Allow a short list of tools, or allow everything and block a few. New app authorizations start with no access, so nothing is reachable until you choose it.
- Fewer places for service credentials. Service tokens are encrypted in Toolstile. Apps use their own Toolstile authorization instead of a copy of the upstream server's token.
- Retire a machine in one step. Devices group the app authorizations made from the same place. Remove the Mac mini's device entry and every app under it loses access across your workspaces.
- A record you can read. Activity answers "which app called what, and did it go through" without pulling logs from four machines.
Suggested access for an engineering workspace
| App and device | Connection | Allow | Block |
|---|---|---|---|
| Codex on the build Mac mini | GitHub | Repository search, read and pull-request tools | delete_repository |
| Codex on the build Mac mini | Linear | Issue search, read and comment tools | Issue deletion |
| Claude Code on the CI runner | GitHub | Pull-request comment and check tools | Everything else stays unavailable |
| Claude Desktop on a laptop | Linear | Issue search and read tools | Everything else stays unavailable |
Choose connection and account permissions together:
Share one approved account across the team
In a team workspace, a member contributes their GitHub or Linear account to a shared entry and an admin approves it. Every authorized app then uses an approved account through the same Toolstile address, and nobody copies a token into a shared config.
Each member's apps use their preferred approved account, or the workspace default. If the selected account needs a fresh sign-in, calls to that connection stop until someone reconnects it. Toolstile never switches to a different person's identity to keep a job running. Before a contributor leaves, they can hand their shared account over to a teammate so the build keeps working.
Connect your first workflow
- Connect the GitHub and Linear remote MCP servers in your workspace and sign in to each.
- Point Codex, Claude Code, Cursor or Claude Desktop at Toolstile and approve the authorization from the app, naming the device it runs on.
- Choose each app's access: allow a list, or allow everything and block the tools you want out of reach.
- Load the permitted tool list from the dashboard to confirm the result before the first real run.
For other remote MCP clients, such as Hermes Agent, OpenClaw, Gemini CLI or OpenCode, follow their vendor's documentation for OAuth sign-in or a Toolstile bearer token. Setup varies by app.
Questions engineering teams ask
Can Toolstile stop an app from force-pushing or deleting a branch?
Only if the server exposes that action as its own tool, which you then block. Toolstile filters by tool name; it does not inspect arguments or know about branches. For git operations the app runs locally, use the repository's own branch protection.
Does Toolstile see our source code?
It processes requests and responses for MCP calls routed through it, which can include source code. Local file edits and tests that do not use those connections stay outside this path. Activity records metadata by default; optional debug capture can store arguments and results for up to 24 hours. Read security and data handling before connecting sensitive repositories.
Can two AI apps on one machine have different access?
Yes. Each app authorization has its own grant, even when both are grouped under the same device. Revoking one leaves the other in place. A device label is a grouping you choose; it is not a check on the hardware itself.
Start with one repository
Connect GitHub, point one app at Toolstile and let it open its first pull request with the tools you chose. Your personal workspace starts free with 5,000 operations a month.