What it can and can't do

The rules on this page are enforced by Valet’s code. They hold whatever the model says or does. What the model says is a separate matter: it can be wrong.

What it can do

Answer questions from live data, using the tools you allow.
Show live cards and draw charts from numbers it already has.
Search documents, bookmarks and photos, if those integrations are there.
Read logs from Docker and from systemd through the Host agent, and say what they show.
File something you attach or paste, and save a link you send, once you approve.
Set a reminder, once you approve. A plain rule checks it every half minute, with no model involved, and it goes to your notification channels.
Make changes you approve.
Pin a card to the page. Only read tools can be pinned, and no model runs after that.

What it can’t do

See your keys. They stay on the server. See secrets.
Reach anything without a tool. It has no shell, no file access and no general web access. It can only do what a tool offers.
Approve itself. A write or control tool needs a press from you.
Give itself more power. See below.
Restart a container. The Docker integration is read-only on purpose. See the threat model.
Act on a read-only page. Without sign-in or auth.trustNetwork, it gets read tools only.

What it may get wrong

It’s a language model, so:

It may misread a tool result, or answer from an old one.
It may name a cause that a tool didn’t show. The prompt tells it not to, and the prompt can be ignored.
maxSteps limits how far it looks. When it runs out, it must answer from what it has.
Small local models are worse at choosing tools.

The cards are real. The sentence beside a card is the model’s reading of it. When they differ, believe the card.

Prompt injection

The assistant reads text written by strangers: feed titles, web pages saved to Karakeep, documents, logs. Any of that can say “ignore your instructions”. A model might listen. Valet assumes it might, and works on what happens next.

Anything that isn’t a read needs your press. A poisoned document can make the model ask. You still see the card.
Background calls have no tools. The brief, the suggestions and the shared-cause line call the model with no tools at all. A poisoned feed title can make it say something odd, and nothing more.
Suggestions can’t carry a stranger’s words. A tapped suggestion goes out as your own message. So the model writes suggestions without seeing feeds, and any suggestion with a link in it is thrown away.
A shared cause must be real. The model’s verdict is believed only if it names at least two of the actual problems.

That leaves real gaps, and you should know them:

A poisoned page can still mislead the answer. It could tell the model to report that all is well.
An approval card written by a tool is reliable. A model’s sentence asking you to approve it is not.
Read tools can move data into the model. With a hosted model, that data leaves your network. There’s no way out from the model to anywhere else unless a tool offers one.

Editing the config

With assistant.access.config, the assistant can help set Valet up by talking to it. Without that key, these tools don’t exist.

Tool	Access	What it does
`config_read`	`read`	Reads the file. Secrets appear as `${NAME}`.
`config_options`	`read`	Looks up what an integration or a section of the config accepts.
`config_preview`	`read`	Tries an edit without saving. Shows the diff, any problems, and the new card.
`api_sample`	`write`	Fetches a JSON URL you gave it, to write a `type: api` block. Asks first.
`config_apply`	`control`	Saves. Always asks.
`config_undo`	`control`	Puts back the version before the last save. Always asks.

So config: read lets it read and preview, and config: control lets it save with your approval.

The limits are in the code, and they apply to saves and previews alike:

It can change integrations, layout, links, menubar, weather, live, nav, hero, chat, format, labels, title, greeting, location, timezone, search, history, welcome, appearance, calendar, recap, notice, and name and suggestions under assistant.
It can’t touch auth, allowedHosts, plugins, mcp, notify, sandbox or the rest of assistant, which holds its access, model and instructions. It can’t raise its own access.
In appearance it can’t name a file on disk: no cssFile, and a wallpaper has to be a URL, a colour or a gradient.
It can’t write a secret. A value that looks like one is refused unless it’s a ${NAME}, and you add the real value to .env yourself.
It won’t save with problems in the result, or with a ${NAME} that isn’t set.
A read-only mount stops it too. Add :ro to the config volume and nothing can be saved: it hands you the diff to paste instead.
With sandbox: true, these tools don’t exist, whatever access says.

These edits go through the same live reload as yours, and your comments and spacing stay as they were.

Attachments

Files attached in chat are kept under data/uploads for a day, up to 50 MB each, and never served back out. They’re for filing. On a read-only page or in a sandbox, attaching is off.

Its own docs

The assistant carries these docs and searches them with docs_search and docs_read, so a question about Valet gets an answer from the docs rather than from what a model remembers. Both only read, and they exist with or without assistant.access.config.

Reporting a problem

report_issue turns a bug, a feature idea or a missing integration into a link to the project’s issue form on GitHub, with the fields filled in. It sends nothing: you read it and submit it yourself. Secrets and private addresses are taken out of the text before it goes into the link, but read it over before you post it.