# Give Your OpenAI Dot Access, Not the Keys

> My OpenAI dot can update my private wiki, work with the services I use, or start a code change, all by voice from the car. Its tasks run on an always-on Mac next to my files, service calls go through n8n workflows that hold the credentials, and code changes stop at a pull request.

Published: 2026-11-06
Canonical: https://tomasparizek.com/2026/11/06/give-your-openai-dot-access-not-the-keys.html

App connectors only got me so far. They didn't cover everything I wanted to do in the services I use, and reaching my [LLM wiki](/2026/08/18/llm-wiki-is-the-input.html) through one would have meant putting my private notes on GitHub.

So I flipped the question. Instead of moving the wiki to where the assistant could see it, I gave the assistant a place to work right next to it: the always-running Mac that already sits under my TV. That Mac also runs n8n, which turns outside services into a short menu of workflows I define and keeps the API keys. Here's how the pieces fit together, and why.

## A Place to Do Work

My assistant is [OpenAI's dot](https://openai.com/index/introducing-dots/). I message or call it in ChatGPT, and the results come back in the same conversation. A dot runs on its own cloud computer and only reaches a personal machine if you connect one. For my Mac, that just meant installing the ChatGPT app and signing in. Now when I ask for something, it can become a Codex task that runs right there, next to my files.

It's worth keeping those two apart. The dot is what tells me a job is done, but the job itself runs on the Mac. That's why each task checks its own work before reporting back. Hearing "done" should mean the change is actually there, not just that a task started.

![Where the assistant's work happens: I talk to my dot, which starts a Codex task on an always-running Mac on my private Tailscale network. The task works directly with the wiki folder, the repositories, and the Scratchpad, and calls n8n workflows by local webhook. n8n holds the API credentials and calls the external services.](/public/images/blog/2026-11-06-assistant-architecture.svg)

Once a task is running on the Mac, it can reach four places, as the diagram shows. Three of them are just local folders: the wiki, the repositories and the Scratchpad. The task reads and writes them directly, with no API or sync step in between. Tailscale is how my own devices reach the Mac privately, but a task reading a file on the same disk never touches it. The fourth one, n8n, is the only path that leaves the machine. The task calls a local webhook on [n8n](https://n8n.io/), and n8n calls the outside service with the credentials it holds.
## Credentials Live in n8n

I route outside services through n8n for three reasons:

- **Credentials stay in one place.** A task never has to be handed a token. It just asks n8n, which already holds the credential.
- **The menu is fixed.** Each workflow is one operation I chose to offer, like creating a time entry, and a task picks one and fills in the inputs. If I never built a workflow that deletes things, deleting simply isn't an option.
- **Every run leaves a trace.** n8n keeps a record of every execution, so that's the first place I look when a result seems off.

There are limits, though. n8n runs on the same Mac as the task, so a task with broad local access could, in principle, reach n8n itself. n8n controls which outside operations are on offer, but it doesn't sandbox the Mac. What a task can touch locally is a separate setting. And the execution records are useful for debugging, but they're not a full audit trail.

I use n8n because I [already run it](/2026/08/18/llm-wiki-is-the-input.html). A small local service with a few well-named endpoints would do the same job.

## Requested, Attempted, Verified

Say I'm driving and ask my dot to log hours on a client project and add a note to the project's wiki page that the release moved to Friday. That one sentence turns into two very different kinds of work.

**The wiki edit stays local.** The task finds the project page, edits it, and then reads the file back. It only counts as done if the page now says what I asked for. Questions work the same way: the answer should come from files the task actually read, and it should be able to tell me which ones.

**The hours go through n8n.** The task calls the time-entry operation, n8n calls the service, and the task checks the response, or the record it created, before telling me the hours are logged.

![From a voice request to a verified result: a request becomes a Codex task, which attempts the work on the matching path and then checks it. Verified results are reported with what changed, and verified code changes become a pull request for my review. Failed or unclear results are reported as not done, with what happened.](/public/images/blog/2026-11-06-assistant-request-flow.svg)

A request is what I asked for, and an attempt is what the task tried. Only a check turns that into a result. If the Mac is asleep or the service rejects the entry, I want to hear "I couldn't log the hours, here's why," not a confident "done" just because a webhook got called.

## Code Ends in a Pull Request

Code changes follow the same pattern, with one extra stop at the end. The task makes a focused change in the local repository, runs the relevant checks, and prepares a pull request for me to review. n8n doesn't play any part here.

Passing checks don't prove the change is right, but they do tell me whether the tests and the build still work, and where they break if they don't. The pull request is where I decide. A request from the car can start the work, but merging and deploying stay with me.

## Chat Is Not an Archive

Assistants generate a lot of files for me: prompts, PDFs, drafts. In my experience, getting back to one of them a few weeks later has been hit and miss. Finding the old conversation takes effort, and even then, picking up from that exact file hasn't been reliable.

So when a task generates a file, it saves the original to the Scratchpad on the Mac and sends me a copy in chat. The chat copy is for right now, and the Scratchpad copy is the one I come back to.

![The artifact lifecycle: a task generates a file and saves the original to the Scratchpad, then delivers a copy in chat. A later request leads the task to find and read the original, update it, save it back, and send a fresh copy.](/public/images/blog/2026-11-06-assistant-artifact-lifecycle.svg)

Later, I can ask for "that onboarding prompt from last month," and the task finds the original, reads it, and picks up from there. Any changes go into the stored original, and I get a fresh copy in chat. So each place has its own job: chat is where results arrive, the wiki holds what I know, and the Scratchpad keeps what was made for me.

## Before You Copy This

- **The Mac has to be on.** If it sleeps or drops off the network, nothing runs, and the assistant should tell you that instead of guessing.
- **Capability isn't permission.** What n8n offers and what a task can touch on disk are two separate settings, and both should stay narrow.
- **Credential placement is one layer.** Keeping tokens in n8n keeps them out of prompts, but not off the machine. It's worth looking at running the integration under its own user, scoping tokens on the service side, and limiting who can reach n8n.
- **Decide what done means.** Each operation needs its own check, and failures should be loud enough that you notice them.
- **Start small.** Offer operations you'd be fine seeing run by mistake, and favor ones that read over ones that delete.

## Takeaways

- **Bring the assistant to your data.** Instead of moving your private files somewhere a connector can reach them, give tasks a machine that sits right next to them.
- **Offer operations, not tokens.** A fixed menu of operations is much easier to reason about than full API access, even if it doesn't sandbox the machine.
- **Done needs evidence.** Requested, attempted and verified are three different things, and only a check gets you to the last one.
- **End code at a pull request.** A voice request can start a change, but a human decides whether it ships.
- **Keep originals outside the chat.** Chat is good at delivering a file. A folder you control is where you'll actually find it again.