"Blocked": the draft and file blocks explained (Google redirect links, overwriting a file in your Booking HQ, and the rename that gets it done)

You asked Otto for something ordinary and got a line back that starts with Blocked: followed by a reason. It arrives in two very different flavours. One is about email, and it usually reads like this: "When otto is trying to draft emails for my gmail account, its saying it's blocked. In the app is says linked...I looked at the settings and seems to be fine." The other is about files: "It seems to have lost the ability to edit its own files in its own workspace folder." This article decodes both. Neither one means something is broken, and nothing was lost.

The exact wording is the whole answer

Blocked is not a general failure and it is not a broken connection. It is one specific rule stopping one specific action and naming itself while it does it. There are around twenty distinct Blocked: lines in the app and every one of them means something different, which is why the wording you saw is the entire diagnosis.

So if you write in, send the verbatim line, ideally a screenshot, plus what you asked Otto to do immediately before it, in your own words. That one sentence identifies exactly one rule. Without it, anyone helping you is guessing at your setup.

What the guard is

Booked Solid OS has a structural safety layer that checks every action before it runs, on every run, even when your autonomy dial is set to Run it. It is not advice to the AI - it stops the action before the tool ever executes. Actions it stops cold include:

• Sending - network commands and tools that would deliver, publish, or post something on their own
• Paying - payment commands and payment services are always denied, at every setting
• Deleting - commands that destroy data
• Reading secrets - credential files, environment variables, and stored keys
• Reaching outside the workspace - including any attempt to touch the app's own data folder, or to rewrite the house rules and play runbooks that constrain the engine
• Overwriting a file you made by hand - changing a file that already exists in your Booking HQ and that Otto did not create itself

Reading a "Blocked:" line

The line names what was attempted and why it was stopped. The common ones decoded:

• Sending a message on the performer's behalf is never automatic - the run tried to send something directly. The message becomes a draft or a decision card for you instead.
• Moving or charging money is never automatic - anything touching payments is stopped, always. There is no setting that changes this.
• Deleting or destroying data is never automatic - a destructive command was refused.
• That draft contains a Google redirect link - the one line that fires specifically on draft actions. You can clear it yourself in a single sentence, see below.
• Changing an existing file the performer made is never automatic - the file guard inside your Booking HQ. It has its own section below, including the rename that gets past it.

Integration settings produce their own blocks too. If you set a connection to read-only on the Permissions tab, tools that create, update, delete, or send through it are denied; a write-only connection denies reading tools. Those blocks reflect your own settings, working as intended, and they are the only family here that a setting of yours can change.

Why is my draft blocked?

Start with the verb you used. If you asked Otto to send the email rather than draft it, that is exactly why you saw a Blocked line. Sending a message on your behalf is never automatic, on any path, at any autonomy setting, including Run it. Otto writes it, it waits in your Drafts, you press send.

If that is what happened, ask him to draft or write the email instead and it goes straight through. The usual next move is to reconnect Gmail, and that is a dead end here - the connection was never involved. Skip that step and change the verb.

"Blocked: that draft contains a Google redirect link"

The full line reads Blocked: that draft contains a Google redirect link. Use the clean destination from the q parameter and create the draft again.

Here is what happened. Otto researched something on the open web, and the link he came back with was a Google tracking redirect, an address in the shape of google.com/url?q=... that carries the real destination inside it, rather than the real web address itself. The guard refuses to put a tracking redirect into a message that is going to a client, so it stops the draft instead of quietly rewriting it for you.

This one you fix yourself in one sentence, with nothing to change in your settings and nothing to reconnect. Tell Otto use the clean web address, not the Google redirect and ask for the draft again.

The Gmail "Linked" badge is not proof either way

When a draft gets blocked, the natural next move is to open Connections, see Gmail showing Linked, and conclude that something in Settings must be wrong anyway. Customers describe it in almost those words: "In the app is says linked...I looked at the settings and seems to be fine", or "Otto says blocked but everything looks connected".

Do not go hunting on the strength of that badge. Linked is a history record. It means this account was linked at some point; it is not a live check of whether the connection works this second. It can read Linked while something underneath is genuinely broken, and it can read Linked while the block you saw had nothing to do with the connection at all. Either way it sends people down the wrong path, so treat it as no evidence rather than as reassurance.

If your Gmail drafts really have stopped working, rather than being stopped by a guard rule, the fix is a different one: move that inbox to a direct IMAP connection with a Google app password. That is covered in Gmail shows Linked but drafts stopped working: switch to an app password.

Otto won't overwrite the file in your Booking HQ

This block arrives sounding like a regression, and it is not one. The line reads Blocked: changing an existing file the performer made is never automatic. People describe it in a handful of ways: "it seems to have lost the ability to edit its own files in its own workspace folder", or Otto won't overwrite the file, or it refuses to edit an existing file, or Otto keeps complaining he can't write the file, or it can create new files but not change them. Same guard, every time.

It shipped in a safety update on 25 July 2026 and it is in every build since. Before that, Otto could overwrite any file in your Booking HQ. It was added because a real customer's hand-built automation script, automation/scripts/check-leads.js, 119 lines of work, was flattened to a one-line stub by an automatic edit during a run. The work was gone, and nothing in the app had stopped it. The first version of the guard shipped in v1.11.13.

What Otto can still do with your files

Worth saying first, because it is far bigger than what he cannot do. Otto can still:

• Create brand new files of any type, anywhere in your Booking HQ. The only exceptions are the protected files in the list above: the house rules, the play runbooks, and anything holding credentials.
• Read any file in there, apart from files that hold credentials.
• Edit his own notes and records freely - anything ending in .md, .markdown or .txt.
• Rename or move a file. Renaming is explicitly allowed, and it is what makes the workaround below work.

What he will not do on his own is overwrite an already-existing file that is not one of those note types: a .json, .csv, .html, .js, .py, any script, any config file. He refuses at every autonomy setting, including Run it. Deleting a file is refused as well.

Three things that do not lift this guard

Customers reach for all three of these, so here they are plainly.

1. There is no folder whitelist. The most common question on this is "can I whitelist that folder somehow", and the honest answer is no. The guard is mechanical. It cannot be pointed at a folder and switched off, and there is no control on Settings > Permissions or anywhere else that lifts it. Permissions governs what your connected tools may do (Gmail, Stripe, Microsoft 365). It has no bearing on files on your disk.
2. Telling Otto he has permission does not work. "I told it support said it was OK and it still won't do it" is exactly right, and expected. This is not a judgement Otto is making in the moment, so there is nobody in there to persuade. The action is stopped before the tool runs.
3. Copying the original does not free the path. Support suggested copying once and then corrected it, so you may have been handed the wrong version of this. A copy leaves the original sitting exactly where it was, Otto still sees a file at that path, and he stops for the same reason as before.

The rename that gets it done

Move the original out of the path rather than copying it, then let Otto write the new file fresh. A brand new file at a free path is always allowed. Renaming is permitted, so Otto can do both steps himself and you do not have to touch anything by hand.

Say this to him, literally:

rename index.html to index-old.html, then write the new index.html

Substitute your own file name. It works because only overwriting-in-place and deleting are refused, and a rename is neither. Keep the renamed original until you have looked at the new file. That is your undo, and it costs nothing.

There is a second route worth knowing for a file you want Otto to keep maintaining from now on: keep it as .md or .txt. He can rewrite those as often as you like.

Why can't Otto update a file he created himself?

That was the fair complaint about the first version of this guard, and it is fixed. The original rule used the file extension as a rough stand-in for the question who made this, which is a poor proxy: it stopped Otto from updating the .html he had generated himself an hour earlier.

Since 1.11.25 the guard is provenance-aware. Otto records each file he creates, so he can keep updating his own work indefinitely - generated site files, a spreadsheet he maintains, a script he wrote - with no rename needed. A file you wrote by hand still stops him cold. That is the intended end state: Otto maintains his own work, and your work is untouchable.

Get the version right. This fix was announced as 1.11.23, but that build failed on the way out and never published. It is in 1.11.25. Confirm you are on 1.11.25 or newer, not 1.11.23.

To update: the app updates itself, so when the Update ready badge appears in the top bar, click it and then click Restart & install. If your copy is not offering updates, install the current build over the top from booked.kivimedia.co/download. The Updates card in Settings names the version you are running. The full walkthrough is in How updates work: the update badge and Restart & install.

Two honest edges, because you may meet them:

• Files Otto created before you updated to 1.11.25 are not in his records. The first attempt to change one of those may still be refused. Use the rename route once and it is recognised from then on.
• If that record is ever lost, the guard falls back to the older, stricter behaviour rather than opening anything up. It fails closed on purpose. So refusals suddenly reappearing is the safety net doing its job, not a regression to fear.

The power user who pushed for this change, someone building whole websites with Otto, came back a few days after the update to say it was going better and Otto was not complaining as much.

What Otto does next

A block does not end the run. The run keeps going, and for anything that would send, publish, or spend, the blocked action takes the drafting path instead: it shows up as a draft for you to review, or as a decision card waiting for your approval. You still get the work - you just get the final say.

A file block behaves differently, and it is worth knowing so you are not waiting for a card that never arrives. There is no draft version of overwriting a file, so Otto reports the refusal and carries on with the rest of the run. Use the rename route above and ask him again.

Good to know

• Every block is written to brain/guard-log.md inside your Booking HQ folder, so you can see exactly what was attempted and when.
• Otto's record of the files he created sits beside it, at brain/otto-authored.log.
• A block is not an error to work around. It is the reason you can turn the dial up with confidence: your files, your accounts, and your money stay in your hands no matter what a run tries.
• If the same block keeps appearing on an integration - the read-only or write-only lines above - check that connection's access level on Settings > Permissions. That is the one family of blocks your own settings produced, and the only one a setting can change. No Permissions setting affects file blocks, sends, payments, or deletions.
• If a run changed a file and you want it back, Undo last run on the Activity screen reverses that run's file changes, and puts them back if you change your mind. See Undo the last run (and put it back).

If it still will not go through

Send us the block itself, not a description of it. The verbatim line, ideally a screenshot, plus what you asked Otto to do immediately before it, names exactly one of the roughly twenty rules, which is what lets us answer without guessing at your setup. If it is a file block, add the file name with its extension and say whether Otto created that file or you did.

Still stuck? Email bookedsolid@kivimedia.freshdesk.com and a person will help.