mirror of
https://github.com/mudler/LocalAI.git
synced 2026-11-03 19:14:56 -05:00
* Store the folder and its mode on a saved agent
A saved agent gets FolderID, the workspace node of its folder, and
FolderMode, read or write. The folder is kept by node so that a rename
or a move is followed. A mode without a node is an agent whose folder
is not chosen yet; Validate accepts it, and refuses a node without a
mode.
The GORM store adds two columns with defaults, so AutoMigrate fills
the rows of existing agents as agents without a folder. The JSON store
reads a file without the keys the same way. Both stores pass the new
contract case.
Assisted-by: Claude:claude-opus-5-5
* Keep on a chat whether its saved agent had a folder
A chat whose agent is deleted runs today without the agent's grants.
When that agent had a folder, nothing is left to say which folder the
chat may read, so the chat must be refused instead of getting the whole
home. ChatRecord.ScopedAgent records that the agent had a folder.
CreateChat writes the flag and SetScopedAgent changes it. UpdateChat
leaves it alone, like the tool switches, so the loop's stale copy of
the record cannot clear it. Both chat stores read chats stored before
the flag as not scoped; the GORM column has a default, so AutoMigrate
is the migration.
Assisted-by: Claude:claude-opus-5-5
* Add the design and plan for agent folder scope
A saved agent works on the whole home folder of its user. The spec
lets the user give an agent one folder and a mode, read only or read
and write, and confines every chat that runs it to that folder.
The workspace store enforces the folder through a fence on the actor,
so a caller that forgets it gets less access, not more. The spec maps
every caller that builds a user actor today, including the host bash,
the sandbox runner and the add-on workspace operations, and how each
is moved to the chat's access.
The plan splits the work into ten lanes; the store fence and the agent
record come first.
Assisted-by: Claude:claude-opus-5-5
* Resolve the folder of a saved agent by node
A person chooses an agent's folder by its path in their home; the
agent keeps the node, so a rename or a move is followed. The new
FolderResolver turns the path into the node and back, always as the
user. A path is refused when it is not a live folder, when it is
LocalAI/ or Chats/ or inside them, or when it names a parent. The
home itself ("/") is allowed.
The workspace stores cannot find a node by its ID yet. PathOf reads
the newest change sets of the home first, checks the path it finds
with Stat, and else lists the folders the user can read. A store that
implements NodeByID is used instead. Nothing is cached, so every
frontend answers the same.
SaveAgent keeps the stored folder when it replaces an agent, so a
caller that knows nothing of folders cannot widen one.
SaveAgentWithFolder sets or clears it. ImportAgent looks the folder of
a file up in the importer's home, and saves a folder that is not there
as unset: the mode without a node, which does not start.
Assisted-by: Claude:claude-opus-5-5
* Add a fence to the workspace actor
A chat whose saved agent has a folder must reach only that folder and
the chat's own folders. The store needs to know which folders those
are on every call, so the actor carries them.
Actor.Fenced returns a copy that reaches only the given folders, by
node ID, each at most at its mode. The fence is an unexported field:
a copy of the actor keeps it, and only Fenced can set it. Fencing a
fenced actor adds a layer, and a node is reached only when every
layer allows it, so a fence never grows.
The helpers in export.go let both store implementations apply the
same rules: the mode a fence allows on a node, its roots, and the
limit of MaxFenceRoots roots per call.
Assisted-by: Claude:claude-opus-5-5
* Show and choose the folder of an agent in the API
The agent routes carry folder. A write takes {path, mode}: the server
turns the path into the folder's node, and refuses with 400 a path
that is not a folder of the user's home, or is LocalAI or Chats. A
write without folder keeps the agent's folder, so a client that does
not know the field cannot widen the agent; {path: ""} clears it. A
read answers the folder's path now, its name, the mode and a state:
ok, missing or unset. The node never leaves the server.
An agent with a folder exports as version 2, with the folder's path
and mode. A server that reads only version 1 refuses that file, so a
scoped agent is never imported elsewhere as one with all the files.
An agent without a folder still exports as version 1. The import
reads both versions and looks the folder up in the importer's home;
a folder that is not there saves the agent as unset, with a warning.
The Swagger spec, the API instructions and the agents docs page show
the field and the new file version.
Assisted-by: Claude:claude-opus-5-5
* Enforce the actor fence in both workspace stores
The store is the one place every file call of a chat goes through, so
it applies the fence: a caller that forgets the agent's folder gets
"not found", never the whole workspace.
- The mode of a fenced actor on a node is the lower of its grants and
the fence. A root in the Trash counts for nothing, and is back after
Undo, because the fence holds the node ID.
- A fenced actor never takes the administrator shortcut, so it cannot
grant, revoke or list grants, and ReadablePrefixes gives only fence
roots or folders inside them.
- A root cannot be deleted, moved or renamed by the fenced actor, by
any path: Move, Delete, Undo, an upper layer, or a delete of a folder
above a nested root.
- A fence with too many roots or a bad root is ErrInvalid.
The shared suite in wstest runs the new specs against the JSON store
and the GORM store (SQLite and PostgreSQL).
Assisted-by: Claude:claude-opus-5-5
* Map the model's paths through the chat's place
A chat's file tools spelled every path as a path in the user's home.
A chat whose agent has a folder sees that folder at /workspace/home and
its own chat folder at /workspace/chat, so the mapping must come from
the mounts of the chat's view, not from the principal.
session.Place maps a path the model writes to a workspace path: "/x",
"x", "home/x" and "/workspace/home/x" are x in the primary mount,
"/workspace/<name>/x" is x in the mount of that exact name, and the
skill layers keep their names. It refuses "..", NUL, control characters
and invalid UTF-8 wherever they point, and a /workspace path that is no
mount. Encoded and look-alike separators stay part of a name. Place is
only a mapping: the store's fence enforces the access.
session.Access holds a turn's actor, view and place. It has no exported
fields and one constructor, so a tool cannot be built from a principal
string. Owner gives the user's own actor without the fence.
Assisted-by: Claude:claude-opus-5-5
* Build a chat's view from its folders and describe it
BuildView took the home of the principal as the folder at
/workspace/home. A chat whose agent has a folder needs that folder
there, at the agent's mode, and its own chat folder beside it.
BuildView now takes the primary folder and the chat folder. The chat
folder is mounted at /workspace/chat, read and write; the name chat is
reserved like the skill layer names. The store caps each mount at the
actor's mode, and a fenced actor gets the shared folders read only.
Every caller passes the home and no chat folder, so an unscoped chat
keeps today's view.
LayoutPrompt takes a ScopedPrompt. A scoped chat hears only of its
folders: the agent's folder by its name and mode, with a line that it
cannot see the user's other files, the chat folder and where its
working files go, and the shared folders. It gets no hint to build a
page, because pages live outside its folder. An unscoped chat keeps
today's text.
Assisted-by: Claude:claude-opus-5-5
* Find a workspace node by its ID
A caller that keeps a node ID, such as the folder of a saved agent,
had no way to ask the store where that node is now. It had to search
the journal and then list folders, which costs one query per folder
in a large home.
Store.NodeByID returns a live node at its current path, so a rename
or a move of the node or of a folder above it is followed. It answers
ErrNotFound when the node or a folder above it is deleted, and when
the actor cannot read it; a fenced actor finds only nodes inside its
fence. Both stores implement it and the shared suite checks it. The
remote store of the Sandbox add-on refuses it, like its other calls.
Assisted-by: Claude:claude-opus-5-5
* Name the work folder of a scoped chat at /workspace/chat
A chat whose agent has a folder keeps its chat folder in the home, but
sees it as a mount of its own at /workspace/chat. Its work folder is
then /workspace/chat/work, not a path under /workspace/home.
workfiles reads /workspace/chat as the chat folder: a helper file under
its work folder is working, a script beside the attachments is a stray
helper, and a folder named chat in the agent's folder is an ordinary
folder. ScopedPrompt steers the model to that work folder and sends the
deliverables to the agent's folder, or to the chat folder when the
agent may only read. It says nothing of pages or of the settings
folder, which are outside the agent's folder. The chat picks the text
by its view.
Assisted-by: Claude:claude-opus-5-5
* Look up the folder of an agent by node
The folder resolver searched the journal of the home and then listed
folders to find where an agent's folder is now. The stores can now
find a node by its ID, so the resolver asks them directly and the
search is gone.
Assisted-by: Claude:claude-opus-5-5
* Resolve the file and media tools through the chat's access
The file tools mapped paths to the user's home and acted as the chat's
actor, and the media tools did the same through files.HomePath. A chat
whose agent has a folder must reach only its folders, and search must
start in the agent's folder, so the count of documents still being
indexed cannot count files elsewhere in the home.
files.Service.Tools and media.Service.Tools take a session.Access. Every
path goes through its place and every call acts as its actor. A write
to a read-only folder is refused before the store sees it. A search
with no path starts at the primary folder, and in a scoped chat also
looks in the chat folder; the pending count is taken below that root.
files.HomePath is removed.
UnscopedAccess builds today's access of a chat (the home and the
shared folders), and the studio service takes the turn's access from
one function, turnAccess, which gives that access until the chat
access resolver replaces it.
The new specs run the paths that try to leave the folder (parents,
absolute and doubled paths, encoded and look-alike separators, NUL,
other cases) through every file tool and the media tools, and check
that nothing outside the folder is read, named or changed, and that
search counts no pending file outside it.
Assisted-by: Claude:claude-opus-5-5
* Resolve the access of a chat at every turn
A chat whose saved agent has a folder must reach only that folder. Up
to now every chat got the user's actor, which reaches the whole home.
The chat's access is now resolved from the stores at every turn
start. With no agent folder it is the actor and the view of today.
With a folder the actor is fenced to the agent's folder at its mode,
the chat's own folder read and write, and the shared folders and the
skill layers read only; the chat's folder is made before the fence,
because a fenced actor cannot make it. A sub-agent takes the folder
of its parent's agent, and its own agent's folder inside it.
A folder that is deleted, unreadable or not chosen refuses the chat
with ErrAgentFolderMissing; it never falls back to the whole home.
A chat records whether its agent had a folder, so a chat whose agent
was deleted is refused too. CreateAs refuses such an agent at once.
session.Access carries the actor and the view, has no exported fields
and one constructor. Open takes it, the turn tools are built from it,
and an open chat compares the fence as well, so an edit of the agent
restarts the harness at the next turn on any frontend. The person's
uploads and renames use the owner's actor, without the fence. The
files a command changed are read as the chat can read them.
Nothing is kept between turns, so frontends cannot disagree.
Assisted-by: Claude:claude-opus-5-5
* List a scoped chat's files by its place in the prompt
The turn prompt lists the chat's files with the paths the model uses.
For a chat whose agent has a folder those paths come from its mounts,
and a file the chat touched outside its folders, for example before
the agent got a folder, must not be named.
Manager.FilesIn is Files with a place. For a scoped place, each file
is named by its mount (/workspace/home for the agent's folder,
/workspace/chat for the chat folder) and a file outside every mount is
left out. Other places give what Files gives. The prompt's file list
uses the turn's place; the chats API keeps the user-wide list.
Assisted-by: Claude:claude-opus-5-5
* Answer 409 when an agent's folder is missing
A chat with a saved agent whose folder is missing or not chosen does
not start. The chat endpoints now say so with 409 and the type
agent_folder_missing, both when the chat is created and when a
message is sent to an open chat, instead of a server error.
The agent docs say what a chat with a folder reaches, when a change
of the folder applies, and that nothing is kept between turns.
Assisted-by: Claude:claude-opus-5-5
* Point a scoped chat at rules and work folders in its own folders
The rules nudge walked from the chat folder up to the home root and
named AGENTS.md files there, and the stray-helper note named the work
folder under /workspace/home. A chat whose agent has a folder must hear
only of its own folders.
The nudge takes the turn's access: it reads paths through the place,
starts at the primary folder (the agent's folder) and stops there, so
it never points above the folder or into the chat folder mount. The
helper note names /workspace/chat/work/ in a scoped chat, and a
sub-agent of a scoped parent gets the scoped work folder text.
Assisted-by: Claude:claude-opus-5-5
* Find workspace actors built outside the chat access
An actor built from a principal has no fence and reaches the whole
home. A spec now parses the studio service, the command runners, the
add-on host operations and the application wiring, and fails on a
workspace.Actor literal, a files.UserActor call or an Actor(principal)
call in a function that is not on the allowlist. Each allowed entry
says why: a host read of the user's settings, a user surface, or a
caller that a later change moves to the chat's access. An entry that
builds no actor any more fails the spec too, so the list stays exact.
Assisted-by: Claude:claude-opus-5-5
* Build the expected view of a chat with the view's folders
The spec of a chat without an agent folder compared its view with
BuildView called with the old arguments, so the test package did not
compile after the merge of the view builder. It now passes the home
as the primary folder and no chat folder, which is the view of an
unscoped chat.
Assisted-by: Claude:claude-opus-5-5
* Give every file tool of a turn the chat's resolved access
The resolver of a chat's access built the view of a scoped chat
itself, with no shared folders, while every other chat got its view
from the session manager. And the file tools, the media tools, the
chat's file list in the prompt, the rules nudge and the work folder
lines each asked for an access of their own, the view of the whole
home. A chat whose agent has a folder therefore had a fenced actor
but home-relative paths: it reached its folder only through paths
such as /Projects/Acme/a.txt, and its prompt named the home.
The session manager now builds every chat's view: UserAccess mounts
the home, and the new ScopedAccess mounts the agent's folder at home,
capped at the fence's mode, the chat folder at chat and the shared
folders read only. It refuses an actor without a fence, and a folder
outside the fence is an error, never a view of the home. The
resolver calls it with the innermost folder, so a sub-agent of a
saved agent still works in its own folder.
The access that the resolver builds once at the start of the turn
now goes down to every consumer. A sub-agent of a saved agent acts
for its parent chat with the same access (Access.ForChat), and a
generic sub-agent gets its tools from the parent's access. The seam
that gave the unscoped access, and the files service's own view
builder, are removed, so a new consumer cannot build a view by
mistake. A turn whose access has no folder gets no tools rather than
the home.
A scoped chat now sees its folder at /workspace/home and its chat
folder at /workspace/chat in its tools, its search, its prompt and
its work folder lines. A chat whose agent has no folder is unchanged.
Assisted-by: Claude:claude-opus-5-5
* Find chat views built outside the chat access
The turn's access is resolved once and handed down, but nothing
stopped new code from building a view of its own, which shows a
scoped chat the whole home. A second scan now parses the same
sources as the actor scan and fails on a call of BuildView,
SkillLayerMounts, NewAccess, UserAccess or ScopedAccess, or on a
store's View, in a function that is not on its allowlist. The
resolver is the one allowed caller; the host bash, the sandbox
runner and the add-on host operations are listed until they take
the chat's access. A stale entry fails the scan too.
Assisted-by: Claude:claude-opus-5-5
* Keep a sub-agent inside its parent's folder
A saved agent started from a scoped chat could name a folder
outside the chat's own, and the child was made before its first
turn failed with a message about a missing folder. spawn_agent now
checks the agent against the chat's agent from the stores before it
makes the child: no folder is fine, the same folder or one inside
it is fine, anything else fails with "this agent works in another
folder than this chat". The child never has more reach than its
parent, in folder or in mode.
The ScopedAgent flag of a sub-agent was reset to what its own
agent had at each turn. A child of a scoped chat with an agent
without a folder lost the mark, so deleting the parent's agent
would have given that child the whole home. The flag now follows
both folders.
New specs cover a generic child, a saved-agent child outside,
inside and at the parent's folder with the lower mode, a child
without a folder, and the work folder wording of a child of a
read-only or read-write parent.
Assisted-by: Claude:claude-sonnet-5-5
* Show agent folders in list_agents and limit them by scope
list_agents gave a scoped chat every saved agent, including ones
that spawn_agent would refuse, and told the model nothing about
where an agent works. Each entry now carries the name of the
agent's folder and its mode, or folder_missing when the folder is
deleted or not chosen. The path is left out, since it would show
the folders above the chat's own. A chat whose agent has a folder
lists only the agents that fit under that folder, by the same check
spawn_agent makes.
The docs for saved agents as sub-agents and for the agent folder
describe both.
Assisted-by: Claude:claude-sonnet-5-5
* Keep the triggers of a scoped agent to its folder
A chat of an agent with a folder reaches only that folder, but its
triggers still worked on the whole home. A file trigger could watch
any folder, the rules of a run were read from the home root down
with the user's actor, the first message named home paths, and a run
whose agent's folder was gone fell through to a failed chat start
after the host had already read the home's rules. The trigger tools
of a scoped chat could also list, change or propose triggers that
reach the whole home.
The agent's folder now bounds every step:
- Saving a file trigger (create, update, edit, confirm) refuses a
folder outside the agent's folder, and a trigger of an agent whose
folder is missing or not chosen.
- Each run checks the agent's folder before it reads anything. A
missing or unset folder skips the run with "the agent's folder is
missing" and switches the trigger off; a watched folder that is not
inside the agent's folder does the same with its own reason. No
chat is made and the owner is told.
- The folder check and the rules are read with an actor fenced to
the agent's folder, read only, so no AGENTS.md above it is read.
The rules of a schedule run start at the agent's folder. The first
message names folders and the file as the chat sees them, under
/workspace/home, and the rules nudge of the run's chat counts those
rules as given.
- In a scoped chat the trigger tools read folders as paths of the
chat's place, refuse one outside the agent's folder, and see only
the triggers of that agent.
The trigger watcher takes the service's administrator actor, made
once next to the change feed's, and the trigger functions leave the
actor scan's allowlist.
Assisted-by: Claude:claude-opus-5-5
* Send connector replies through the chat's access
The files a connector reply sends were listed from every change made
in the chat's name and read with the user's actor, so a reply of an
agent limited to one folder could send a file from anywhere in the
home that some host-side write had attributed to the chat. A message
to an agent whose folder was missing made or reopened a chat, failed
to start it, and answered with a generic error.
A reply now resolves the chat's access once, lists the turn's files
through its place (a file outside the chat's folders is left out)
and reads each one with its fenced actor. A file the access cannot
reach is skipped without being named. Before it makes a chat, a
message checks the bound agent's folder; when it is missing or not
chosen, the sender gets one reply, "This agent cannot work right
now: its folder is missing.", the refusal is logged and the binding
stays on. The same reply covers a folder that goes away between the
check and the turn. readChatFile leaves the actor scan's allowlist.
Assisted-by: Claude:claude-opus-5-5
* Name a read-only refusal of a commit by its guest path
The store names an upper entry that a read-only mount refused by
its path in the view (/home/x), not by its store path. The note
that a command's output ends with took every path but an
outside-view one for a store path, so it told the model that
"/home/x was not saved", a path the guest does not have. A path
that no mount holds but that starts with a mount name is now taken
as a path of the view and gets the /workspace prefix.
Assisted-by: Claude:claude-opus-5-5
* Take the actor and view of command runners from the chat's access
The host bash and the sandbox runner made their own actor and view:
the host bash a user actor from the principal and the view of the
whole home, the sandbox runner a plain actor by default and the view
from its own mount requests. Neither knew the chat's agent folder,
so a command of a scoped chat could reach the whole home.
The runner now has no default actor or view. Options.Actor takes a
context and returns an error, and Options.View returns the view
itself; both are asked at every call. A view of another actor than
the chat's is refused, and a sandbox whose actor or mounts changed
is made again, so an agent's new folder or mode applies from the
next command. A failing resolver fails the call, also with a sandbox
running.
The server wires both hooks to the chat's resolved access: the new
Service.CommandActor and Service.CommandView, the latter refusing an
actor that is no longer the chat's. Access.SandboxView adds the skill
layers to the turn's view, at the names the file tools use. The host
bash refuses a fenced actor, at the tool and again at each call, as a
command on this machine reads what the server can read. The Sandbox
add-on passes a label actor and its home view: the host binds each
workspace operation to the call's chat.
The lane 5 entries leave the actor and view scan allowlists.
Assisted-by: Claude:claude-opus-5-5
* Offer no host bash to a chat whose agent works in one folder
A command of the built-in bash runs on this machine and reads every
file LocalAI can read. No workspace rule confines it, so a chat whose
agent works in one folder cannot have it, whatever chats_host_exec
says. The tool's build now refuses a fenced actor, so the chat gets
no bash, its prompt says nothing runs commands, and the shell group
of the Tools menu gives the reason: the agent works in one folder
and runs commands only in the Sandbox add-on. Sub-agents of such a
chat have the fenced actor too.
The docs of saved agents and of the commands on this machine state
the rule and the Sandbox layout of a scoped chat.
Assisted-by: Claude:claude-opus-5-5
* Tell a scoped chat where its Sandbox commands start and what they keep
The commands block of the prompt told every chat with the Sandbox
that a command starts in /workspace/home, the user's home, and that
what it saves there or in a writable shared folder is kept. In a
chat whose agent works in one folder, /workspace/home is that folder,
the chat folder is /workspace/chat and the shared folders are read
only. The block now says so, and with a read-only folder it names
only /workspace/chat as kept.
Assisted-by: Claude:claude-opus-5-5
* Name a scoped chat's attachments where its commands see them
The model learns of an attached file by its guest path, which was
always /workspace/home/Chats/<chat>/<file>. In a chat whose agent
works in one folder, /workspace/home is that folder: the file and
media tools still found the file through the place's chat alias, but
a command sees the chat folder only at /workspace/chat, so the path
named nothing for it.
The text the model gets now names a file of the chat folder at
/workspace/chat/<file> in a scoped chat, through the chat's place:
when a message is sent, queued or injected, in the summary of the
chat, and in the model state rebuilt after an edit, a regenerate, a
fork or an import. What is stored keeps the home spelling, which
SplitMessage reads back, and an unscoped chat is unchanged.
Assisted-by: Claude:claude-opus-5-5
* Remove the duplicated allowlist entries of the actor scan
Assisted-by: Claude:claude-opus-5-5
* Read and write the folder of an agent in the agent helpers
The agent API now answers an agent's folder with its path, mode and
state, and a write keeps the stored folder unless it names one. The
page helpers learn that shape: the folder field of a save is sent only
when the person changed it, an empty path clears it, a missing or
unset folder that the person did not replace is kept, and the mode is
read unless write was chosen. Small helpers say whether a listing
entry can be chosen (not a folder LocalAI manages, not a shared
folder), which folders agents use for the Files page marker, and
whether a chat error is the missing-folder conflict.
Assisted-by: Claude:claude-opus-5-5
* Move the folder walk of the Move dialog into a folder picker
The agent editor needs the same walk through the person's folders as
the Move dialog, so the breadcrumb and the folder list move into
FolderPicker, with their styles, and the Move dialog draws it. The
picker can show a folder as one that cannot be chosen, with the
reason next to it, and a folder that cannot be read now offers to try
again; a folder still loading says so instead of an empty list.
Assisted-by: Claude:claude-opus-5-5
* Choose the folder of an agent in the agent form
The agent form gets a Files section after the instructions: All my
files, or One folder chosen in the folder picker, and whether the
agent's chats can read the folder or read and change it. The picker
shows the folders LocalAI manages as ones that cannot be chosen, and
Home itself can be chosen. A folder that was deleted, or an imported
agent whose folder was not found, is said in place with an offer to
choose another; the rest of the form still saves and keeps it.
A save sends the folder only when the person changed it, so editing
another field never touches it. Picking One folder and choosing
nothing stops the save, as it would otherwise save an agent on all
the files. The Export section now downloads the file the server
writes, which names the folder, and says so.
Assisted-by: Claude:claude-opus-5-5
* Show the folder of an agent on the agents list and its page
An agent with a folder shows it in the list's line and on its page,
with its access in words and a lock when its chats can only read it.
A folder that is gone, or an agent with no folder chosen yet, shows
a warning that opens the form; the agent's page also says so above
its facts and offers to choose another folder.
Assisted-by: Claude:claude-opus-5-5
* Mark the folders that agents work in on the Files page
A folder that a saved agent works in gets a small marker with the
agent's name, or the number of agents, and a tooltip that names each
one with its access. Inside such a folder, a line over the list says
the same. The page reads the agent list it can already fetch, so the
files API is unchanged, and the page still shows all the files.
Assisted-by: Claude:claude-opus-5-5
* Show a chat's folder and say when its agent's folder is missing
A chat with an agent that has a folder shows the folder next to the
agent in the message box, with a lock for read only, and the Tools
menu says which files the chat's tools reach. When the folder is
gone, the chip says so and opens the agent's form.
A chat whose agent's folder is missing does not start, and the server
answers with a conflict. The message box now says that in plain words,
keeps the message, and offers Edit agent, instead of the server's
text.
Assisted-by: Claude:claude-opus-5-5
* Test the folder of an agent across the web interface
The agent stubs now list folders by path, read a written folder back
as the server does, export a version 2 file for an agent with a
folder, import one whose folder is not found as unset, and refuse to
start a chat whose agent's folder is missing.
The specs choose a folder and see it on the list, switch the access,
leave an unchanged folder out of the save, clear it, keep and replace
a missing folder, keep Chats and LocalAI out of the picker, retry a
folder that cannot be read, see the Files marker, the chat's chip and
Tools line, the missing-folder chat error with Edit agent, and the
import warning. A render smoke opens the picker on the real server,
and one spec checks that the copy names no internal path.
Assisted-by: Claude:claude-opus-5-5
* Describe the agent's folder in the web interface
The agent docs said what the folder field does in the API. They now
also say where the web interface sets it, how the agents pages, the
Files page and a chat show it, and what a chat whose folder is
missing offers.
Assisted-by: Claude:claude-opus-5-5
* Record the chat an add-on call was made for
An add-on's workspace operations run as the user of the live request,
with no idea which chat made it. Only an action carries a chat, and
only as a key in its resource ID; a read tool such as the Office
add-on's read-docx carries none. So a chat that should reach only one
folder could reach the whole home through an add-on.
The in-flight record of a request now keeps, next to the envelope, a
binding to the chat the request was made for: the user's principal
and the chat ID. It is host-side only and never a field of the
envelope, which installed add-ons decode with unknown fields refused.
A context carries the binding from the chat turn to the place that
records the request. The broker gives each host operation the chat
and the scope of its live request. An operation ID that requests of
two chats share is not live, so neither chat is trusted.
Assisted-by: Claude:claude-opus-5-5
* Keep the chat binding of a runtime call on the host
The runtime client records each call's envelope for the host operation
channel. It now records the chat binding too when the call's context
carries one, so the add-on's host operations know which chat made the
request. The envelope sent to the add-on is the same bytes with or
without a binding: a spec checks that the body of a bound call equals
the body of an unbound one and still decodes with unknown fields
refused.
Assisted-by: Claude:claude-opus-5-5
* Carry the chat binding in a forwarded add-on request
A frontend that is not the add-on owner forwards an add-on call in a
signed request. The chat the call was made for now rides in that
request as a signed field, chat, and the owner puts it back on the
context of the call it serves, where the runtime client records it.
A changed, added or removed binding fails the signature check, and a
signed but incomplete one is refused. A request that no chat made has
no chat field and signs as before.
An owner that does not know the field refuses a forwarded call that a
chat made, so the owner must be upgraded before the frontends.
Assisted-by: Claude:claude-opus-5-5
* Bind every add-on tool call of a chat to the chat
The chats consumer ran an add-on tool with the conversation ID only,
which the owner used to resolve a selection and, for an action, as the
key of the add-on's state. Nothing told the host which chat a read
tool or a change came from.
The tool adapter now has ExecuteChat, which takes a ChatCall (the
chat's user and ID, from the chat turn's own record) and binds the
call to the chat on the host side for every tool kind: a read with no
resource, an action, and a change made at once. The chats adapter
refuses a call that names a conversation without that binding, so a
chat's call cannot be made unbound by mistake. Other consumers, such
as the OpenAI-compatible route, keep calling without a binding.
Assisted-by: Claude:claude-opus-5-5
* Run add-on workspace operations with the chat's access
The workspace operations of add-ons (materialize, commit, changes,
export and import) worked on the whole home of the request's user. A
chat whose agent has a folder could therefore read and write any file
through the Office or Sandbox add-on.
They now resolve their access from the chat binding of the live
request, through a new Access hook that the chats service answers
(Service.AddonAccess). A chat's call gets the chat's access, as its
file tools do: in a chat whose agent has a folder, the add-on's "/" is
that folder, /workspace/chat names the chat folder, the agent's mode
applies, and paths resolve through the chat's place, so a parent
reference is refused and an encoded separator is part of a name. The
mounts go through Access.SubView, which builds a view only inside the
access, for its fenced actor. When an add-on mounts its "/" at home,
the host adds the chat folder at chat, so the Sandbox sees the chat's
layout without a change. Changes list only what the access may read,
and a commit entry outside the view is a conflict.
A call whose chat cannot be resolved is refused and never runs
user-wide. An action request without a binding is resolved by its
chat key, as before, and refused when it names no chat. A call that
no chat made (an add-on page, the OpenAI-compatible route) still works
on the whole home, through Manager.PersonAccess.
The four lane 6 entries leave the actor scan and the view scan.
PersonAccess joins the view scan's matcher, with AddonAccess as its
one allowed caller. An end-to-end spec runs the real Office and
Sandbox add-ons in a scoped chat.
Assisted-by: Claude:claude-opus-5-5
* Build the chat access of the file index route test
files.Service.Tools takes a session.Access since the chat access
change, so the route test of the text index passed a bare actor and
its package did not compile under the auth tag.
The test now builds the access as the chats service does for a chat
whose agent has no folder: the user's home as the primary folder of
the view, then session.NewAccess. The assertions are unchanged.
Assisted-by: Claude:claude-opus-5-5
* Test the folder of an agent through every surface of a chat
The specs of the folder feature each test one surface. This suite
runs one chat of an agent limited to a folder through all of them at
once, on an indexed SQL workspace: the file and media tools, the search
and its pending count, a command of the Sandbox in a fake sandbox, a
read call and an action call of an add-on through the real workspace
operations bound to the chat, a generic and a saved sub-agent, the
trigger tools, a file trigger run, a connector reply, a renamed folder,
a mode change, an edit that narrows the folder (also seen by a second
frontend) and a deleted folder.
The files outside the folder hold a token that the scripted model never
writes. After each spec the suite collects every text a person or a
model can see: tool results and errors, prompts, messages, transcripts
with their cards, live events, chat file lists, tool panels,
notifications, connector replies and files, the add-on's data directory
and the connector log. The token must be in none of them, and the files
outside must be unchanged.
A control spec runs the same probes from an agent without a folder and
checks that they do find the token, so the probes and the collection
cannot pass by seeing nothing.
Assisted-by: Claude:claude-opus-5-5
* Complete the docs of the folder of an agent
Each change of the folder feature documented its own part. This
makes the pages one account of it:
- Saved agents: the missing and unset states in one bullet, what the
folder does not limit (MCP servers, web tools, collections, pages),
that the Files page stays user-wide, when an edit applies, the
downgrade caveat, and the folder as a stateless row of the cluster
table. The Sandbox of a scoped chat mounts the agent's folder and the
chat folder only, as the add-on asks for them; the page said it also
had the shared folders and skills.
- Chats: the chat folder at /workspace/chat for the model, sub-agents
of a scoped chat, and commands only in the Sandbox.
- Add-ons: the Sandbox and Office sections say what / is in a chat whose
agent has a folder.
- First agent: the optional folder step and the "Folder missing" case.
Assisted-by: Claude:claude-opus-5-5
* Draft the PR description and release note of agent folders
No release notes file exists for the next release yet, so the draft
text lives next to the spec and the plan. It carries the release note
paragraph with the downgrade caveat and the upgrade order of a cluster.
Assisted-by: Claude:claude-opus-5-5
* List the chat binding specs in the per-report add-on inventories
The chat binding change added five specs to the gateway and runtime
packages and named them in the case lists of the gateway, artifacts and
apps suites. These three suites also keep one case list per Ginkgo
report, and the verifier compares each report with its own list. The
new names were missing there, so the three suites failed with an
inventory mismatch.
A dry run of every Ginkgo suite's commands now lists the same It names
as each report's inventory, in both directions.
Assisted-by: Claude:claude-opus-5-5
* Hide stale paths from a fenced actor's history
A folder moved into a fence makes its parent identities readable.
Their historical paths can still name locations outside the fence.
Hide each historical side when its readable parent's current path
differs. Reuse the generic title when filtering hides a side. Keep
the journal and unfenced history unchanged so Undo uses identities.
Assisted-by: nib:gpt-6.1-sol
* List the chat binding cases in Tables tools
The Tables tools runner includes every adapter spec in its output.
List the four chat binding cases so the exact inventory accepts them.
Assisted-by: nib:gpt-6.1-sol
* Keep shared agent folders unset in exports
A followed folder outside the home cannot round-trip through a home path.
Export its mode with an empty path so import warns and stays fail-closed.
Responses keep public shared paths without exposing other internal paths.
Distinguish deleted scoped agents from unscoped agents in the guidance.
Assisted-by: nib:gpt-6.1-sol
* Refuse scoped chats over the folder limit
Keep every required shared root in each intersecting fence. Refuse
creation and turn access when the complete set exceeds 32 roots.
Reserve a chat root before its folder exists and fence listings empty
on refusal. Propagate shared enumeration failures instead of omitting
roots.
Map capacity refusals to a fixed 409 response and give connectors a
safe capacity message. Check boundaries, retries, background access,
and HTTP handlers with focused regressions.
Assisted-by: nib:gpt-6.1-sol
* Verify unset imports refuse chat startup
Assert the folder-specific refusal without a harness start or saved chat.
Clarify public response paths and unset exports in the API metadata.
Assisted-by: nib:gpt-6.1-sol
* Keep the folder retry test under user control
A background refresh consumes the one-shot successful response before
this test observes its load error. Isolate the mocked Files page from
the live workspace stream and agents list. Keep reads failing until
the error assertions pass, then allow the actual Retry click to recover.
Check that Retry reads again and removes the error, without changing
the existing assertions or their timeouts.
Assisted-by: nib:gpt-6.1-sol
* Test and document folder capacity refusals
Use the existing Ginkgo suites for capacity regressions. Exercise a
successful turn, refusal after shares change, and a retry through a
second service on the same stores. Check that refusal leaves no claim
or pending message.
Verify that connectors send one fixed refusal and that triggers stay
enabled after capacity failures. Document the 32-root budget and the
all-required-roots-or-refuse contract.
Assisted-by: nib:gpt-6.1-sol
* Control crashes in the restart budget test
The crash fixture exits after 100 ms, before startup necessarily finishes.
A busy runner can fail the readiness handshake instead of testing restarts.
Start a normal fixture and kill each published incarnation explicitly.
Keep the exact restart count and persistent failed-state assertions.
Assisted-by: nib:gpt-6.1-sol
* Check capacity test cleanup errors
Assert service and workspace cleanup through Ginkgo. Keep service cleanup before workspace cleanup and report close failures instead of discarding them.
Assisted-by: nib:gpt-6.1-sol
---------
Co-authored-by: Ettore Di Giacinto <mudler@localai.io>
786 lines
32 KiB
Go
786 lines
32 KiB
Go
// SPDX-License-Identifier: MIT
|
|
|
|
// Package tools adapts the tools of installed add-ons to model tool calls.
|
|
//
|
|
// The adapter is the one place where a model-facing consumer (chat, an
|
|
// agent, a scheduled job) meets add-on tools. It never decides authority:
|
|
//
|
|
// - discovery shows only what the owner lists for the authenticated actor:
|
|
// enabled, running add-ons with a tool definition in their verified
|
|
// manifest;
|
|
// - a read goes to the gateway read path with that actor;
|
|
// - a change, a schema change or a creation goes to the proposal broker and
|
|
// returns a reference to the stored proposal. The adapter has no way to
|
|
// confirm, cancel or resolve a proposal: Backend does not name those
|
|
// operations, so a tool call can never apply a change;
|
|
// - the actor is a value the consumer took from its authenticated request
|
|
// or job principal. Nothing in the arguments can change it, and any
|
|
// argument that names identity, role or approval is refused.
|
|
package tools
|
|
|
|
import (
|
|
"context"
|
|
"crypto/rand"
|
|
"encoding/hex"
|
|
"encoding/json"
|
|
"errors"
|
|
"fmt"
|
|
"regexp"
|
|
"slices"
|
|
"strings"
|
|
"time"
|
|
|
|
"github.com/mudler/LocalAI/core/services/addons/apps"
|
|
"github.com/mudler/LocalAI/core/services/addons/gateway"
|
|
"github.com/mudler/LocalAI/core/services/addons/hostops"
|
|
addonruntime "github.com/mudler/LocalAI/core/services/addons/runtime"
|
|
"github.com/mudler/LocalAI/core/services/addons/toolargs"
|
|
"github.com/mudler/LocalAI/pkg/addons/contract"
|
|
)
|
|
|
|
const (
|
|
// Prefix starts the name of every add-on tool. Names have the form
|
|
// addon__<addonId>__<tool>: letters, digits, hyphen and underscore, so
|
|
// they are valid function names for the OpenAI tool format. An add-on ID
|
|
// and a tool name never contain an underscore.
|
|
Prefix = "addon__"
|
|
// MaxNameLength is the longest function name providers accept.
|
|
MaxNameLength = 64
|
|
// MaxArgumentBytes bounds the arguments of one call.
|
|
MaxArgumentBytes = toolargs.MaxArgumentBytes
|
|
// MaxResultBytes bounds a read result handed to a model. A larger result
|
|
// is refused: a truncated JSON document would read as a complete one.
|
|
MaxResultBytes = 128 << 10
|
|
// MaxAppliedBytes bounds each excerpt copied into the result of a change
|
|
// made at once. The chat keeps a tool result capped at 2 KiB, so the whole
|
|
// document must stay well under it to remain valid JSON there.
|
|
MaxAppliedBytes = 512
|
|
// MaxTools bounds the tools one discovery returns.
|
|
MaxTools = 64
|
|
// MaxSummaryBytes bounds the effect sample copied into a proposal
|
|
// reference. The approval card loads the full preview from the host.
|
|
MaxSummaryBytes = 4 << 10
|
|
)
|
|
|
|
var (
|
|
// ErrUnknownTool means the name is not a tool this actor may call now:
|
|
// not in the namespace, not defined by the manifest, or its add-on is
|
|
// disabled, stopped or not visible to the actor. Approval, sharing,
|
|
// deletion and purge names land here: no such tool exists.
|
|
ErrUnknownTool = errors.New("addon tool not available")
|
|
// ErrForbiddenArgument means the arguments carry a field that stands for
|
|
// identity, authority or approval.
|
|
ErrForbiddenArgument = toolargs.ErrForbiddenArgument
|
|
// ErrInvalidArguments means the arguments are not what the tool schema
|
|
// declares.
|
|
ErrInvalidArguments = toolargs.ErrInvalid
|
|
// ErrResultTooLarge means a read result is too large for a model.
|
|
ErrResultTooLarge = errors.New("addon tool result is too large; narrow the request")
|
|
)
|
|
|
|
// Backend is what the adapter needs from the owner. It deliberately names no
|
|
// way to confirm, cancel, reconcile or resolve a proposal.
|
|
type Backend interface {
|
|
// Apps lists the add-ons the actor may see.
|
|
Apps(ctx context.Context, actor contract.Actor) (apps.List, error)
|
|
// Dispatch runs a typed read.
|
|
Dispatch(ctx context.Context, actor contract.Actor, request contract.Request) (contract.Result, error)
|
|
// Propose stores a change for a person to confirm. It never applies.
|
|
Propose(ctx context.Context, actor contract.Actor, request contract.Request) (gateway.Proposal, error)
|
|
}
|
|
|
|
var _ Backend = (*gateway.Gateway)(nil)
|
|
|
|
// Selector resolves the resource a conversation selected. The owner
|
|
// authorizes the stored reference for the actor on every call, so the answer
|
|
// is never a credential. A Backend that does not implement it has no
|
|
// conversation selection: a call that omits the resource is invalid.
|
|
type Selector interface {
|
|
ResolveSelection(ctx context.Context, actor contract.Actor, conversationID, addonID string) (string, error)
|
|
}
|
|
|
|
var _ Selector = (*gateway.Gateway)(nil)
|
|
|
|
// ToolDefinition is one tool as a model sees it.
|
|
type ToolDefinition struct {
|
|
// Name is the namespaced function name.
|
|
Name string `json:"name"`
|
|
AddonID string `json:"addonId"`
|
|
Tool string `json:"tool"`
|
|
Kind string `json:"kind"`
|
|
Description string `json:"description"`
|
|
Parameters map[string]any `json:"parameters"`
|
|
// Shadows is the built-in chat tool this tool replaces in a chat (see
|
|
// contract.ToolDefinition.Shadows), or empty. Only the chat consumer acts
|
|
// on it; every other consumer keeps the namespaced Name.
|
|
Shadows string `json:"shadows,omitempty"`
|
|
// InstalledAt is when the add-on was first installed (RFC 3339, UTC), or
|
|
// empty. The chat consumer ranks the add-ons that shadow one name by it.
|
|
InstalledAt string `json:"installedAt,omitempty"`
|
|
}
|
|
|
|
// ResultKind says what a ToolResult carries.
|
|
type ResultKind string
|
|
|
|
const (
|
|
// ResultData is a read result.
|
|
ResultData ResultKind = "result"
|
|
// ResultProposal is a reference to a stored proposal. Nothing is applied.
|
|
ResultProposal ResultKind = "proposal"
|
|
// ResultApplied says a change tool ran for a chat and the change is made.
|
|
ResultApplied ResultKind = "applied"
|
|
// ResultArtifact is a reference to a private file the add-on produced.
|
|
ResultArtifact ResultKind = "artifact"
|
|
// ResultError is a typed answer that asks the person to act: no resource
|
|
// is selected for the conversation. It is a result, not a transport
|
|
// failure, so the model can tell the person what to do.
|
|
ResultError ResultKind = "error"
|
|
)
|
|
|
|
// CodeSelectResource is the Code of a ResultError for a tool call that named
|
|
// no resource in a conversation that has none selected.
|
|
const CodeSelectResource = "select_resource"
|
|
|
|
// CodeInvalidRequest is the Code of a ResultError for a call the add-on
|
|
// refused as invalid. Nothing was changed, so the model corrects the call
|
|
// instead of reporting an outage or retrying it unchanged.
|
|
const CodeInvalidRequest = "invalid_request"
|
|
|
|
// InvalidNote is what the model is told when the add-on refused a call.
|
|
const InvalidNote = "The add-on refused this request as invalid. Nothing was changed. Check the arguments against the tool description and correct them; do not repeat the same call and do not report an outage."
|
|
|
|
// ReasonedNote is what the model is told when the add-on refused and said why.
|
|
const ReasonedNote = "The add-on cannot do this now, and says why in message. Nothing was changed. Tell the person what it said in plain words; do not repeat the same call and do not report an outage."
|
|
|
|
// CodeNotRunning is the Code of a ResultError for a call that found the add-on
|
|
// not running. Nothing was sent.
|
|
const CodeNotRunning = "not_running"
|
|
|
|
// NotRunningNote is what the model is told when the add-on is not running.
|
|
const NotRunningNote = "The add-on is starting or stopped, so nothing was sent and nothing was changed. Tell the person to try again in a moment; you may try the same call once more later."
|
|
|
|
// CodeNotPermitted is the Code of a ResultError for a call the person is not
|
|
// allowed to make, for example without the fine-tuning permission.
|
|
const CodeNotPermitted = "not_permitted"
|
|
|
|
// NotPermittedNote is what the model is told when the person lacks a permission.
|
|
const NotPermittedNote = "The person does not have the permission this tool needs. Nothing was changed. Tell them an administrator must grant it; do not repeat the call and do not report an outage."
|
|
|
|
// CodeResourceUnreachable is the Code of a ResultError for a resource the person cannot reach.
|
|
const CodeResourceUnreachable = "resource_unreachable"
|
|
|
|
// ResourceUnreachableNote is what the model is told when a resource cannot be used.
|
|
const ResourceUnreachableNote = "That resource does not exist or the person has no access to it. Nothing was changed. Ask which resource to use, or ask them to choose one; do not guess an ID and do not repeat the call."
|
|
|
|
// SelectNote is what the model is told when no resource is selected.
|
|
const SelectNote = "No resource is selected for this conversation. Ask the person to choose one with the Select action of the add-on in the chat, or to give its ID. Do not guess an ID."
|
|
|
|
// ProposalRef is what a model and a chat learn of a stored proposal. The
|
|
// approval card reads the authoritative record from the host by ID; model
|
|
// text is never the preview.
|
|
type ProposalRef struct {
|
|
ID string `json:"id"`
|
|
AddonID string `json:"addonId"`
|
|
ResourceID string `json:"resourceId"`
|
|
Action string `json:"action"`
|
|
Digest string `json:"digest"`
|
|
State string `json:"state"`
|
|
Count uint64 `json:"count"`
|
|
Summary json.RawMessage `json:"summary,omitempty"`
|
|
ExpiresAt time.Time `json:"expiresAt"`
|
|
}
|
|
|
|
// AppliedRef is what a chat learns of a change it made. The person enabled the
|
|
// add-on for the chat or the agent, which is the consent, so the change is made
|
|
// at once. The safety net is undo: when the add-on kept a change set for the
|
|
// change, Undoable is true and ChangeID names it; the person undoes it from the
|
|
// chat with a button, and the model cannot, because the undo route accepts the
|
|
// person's own browser session only. When it kept none, Reason says why.
|
|
type AppliedRef struct {
|
|
// ID is the operation ID of the change.
|
|
ID string `json:"id"`
|
|
AddonID string `json:"addonId"`
|
|
ResourceID string `json:"resourceId,omitempty"`
|
|
Action string `json:"action"`
|
|
Count uint64 `json:"count"`
|
|
Summary json.RawMessage `json:"summary,omitempty"`
|
|
// Result is what the add-on's receipt reported.
|
|
Result json.RawMessage `json:"result,omitempty"`
|
|
// Undoable says whether the person can roll the change back.
|
|
Undoable bool `json:"undoable"`
|
|
// ChangeID is the change set to undo, when Undoable.
|
|
ChangeID string `json:"changeId,omitempty"`
|
|
// Undo says in one line what the undo will do, when Undoable.
|
|
Undo string `json:"undo,omitempty"`
|
|
// Reason says why the change cannot be undone, when it cannot.
|
|
Reason string `json:"reason,omitempty"`
|
|
}
|
|
|
|
// ArtifactRef points at a private artifact. The bytes are fetched by the
|
|
// person's authenticated session, never through a tool result.
|
|
type ArtifactRef struct {
|
|
ID string `json:"id"`
|
|
Name string `json:"name"`
|
|
MediaType string `json:"mediaType"`
|
|
Size int64 `json:"size"`
|
|
}
|
|
|
|
// ToolResult discriminates a read result, a host proposal reference and
|
|
// private artifact references.
|
|
type ToolResult struct {
|
|
Kind ResultKind `json:"kind"`
|
|
Tool string `json:"tool"`
|
|
Result json.RawMessage `json:"result,omitempty"`
|
|
Proposal *ProposalRef `json:"proposal,omitempty"`
|
|
Applied *AppliedRef `json:"applied,omitempty"`
|
|
Artifacts []ArtifactRef `json:"artifacts,omitempty"`
|
|
// Code says what the person is asked to do, for a ResultError.
|
|
Code string `json:"code,omitempty"`
|
|
// Message is the reason the add-on gave for refusing, in a short fixed
|
|
// sentence such as a missing engine. It is empty when the add-on gave none.
|
|
Message string `json:"message,omitempty"`
|
|
// Note is host text for the model: a proposal is not applied.
|
|
Note string `json:"note,omitempty"`
|
|
}
|
|
|
|
// ProposalNote is what the model is told after a proposal.
|
|
const ProposalNote = "Nothing has been changed. A person must review and confirm this proposal in the approval card. Do not say the change was made."
|
|
|
|
// AppliedNote is what the model is told after a change it made in a chat that
|
|
// cannot be undone. The reason follows it in the result.
|
|
const AppliedNote = "The change was made. It cannot be undone: see the reason. Tell the person plainly what changed and that it cannot be undone."
|
|
|
|
// UndoableNote is what the model is told after a change it made in a chat that
|
|
// the person can undo. Only the person can: the button is theirs.
|
|
const UndoableNote = "The change was made. The person can undo it with the Undo button on this change in the chat; you cannot undo it. Tell the person plainly what changed and that they can undo it."
|
|
|
|
// noUndoReason is the reason when the add-on kept no change set and said
|
|
// nothing more.
|
|
const noUndoReason = "the add-on keeps no change set for it"
|
|
|
|
// Applier is the owner side of a change the chats consumer makes at once. It is
|
|
// separate from Backend so that no consumer that holds only a Backend can apply
|
|
// a change, and the adapter has no method that confirms anything: the chats
|
|
// adapter confirms only the proposal it has just stored for the same actor.
|
|
type Applier interface {
|
|
// ConfirmProposal applies the stored proposal once.
|
|
ConfirmProposal(ctx context.Context, actor contract.Actor, id, digest string) (gateway.Proposal, error)
|
|
// CancelProposal withdraws a pending proposal.
|
|
CancelProposal(ctx context.Context, actor contract.Actor, id string) (gateway.Proposal, error)
|
|
}
|
|
|
|
var _ Applier = (*gateway.Gateway)(nil)
|
|
|
|
// ToolAdapter exposes add-on tools to model consumers.
|
|
type ToolAdapter struct {
|
|
// actions says that this adapter serves action tools. Only the adapter of
|
|
// the chats consumer is built with it; every other consumer neither lists
|
|
// nor runs an action tool.
|
|
actions bool
|
|
apply Applier
|
|
backend Backend
|
|
newID func() (string, error)
|
|
}
|
|
|
|
// NewToolAdapter returns an adapter over the owner.
|
|
func NewToolAdapter(b Backend) *ToolAdapter {
|
|
return &ToolAdapter{backend: b, newID: randomOperationID}
|
|
}
|
|
|
|
// ActBackend is the owner side of action tools. It is separate from Backend so
|
|
// that no consumer that holds only a Backend can run one.
|
|
type ActBackend interface {
|
|
// Act runs an action tool for the actor and returns its answer. It never
|
|
// proposes and never repeats a call.
|
|
Act(ctx context.Context, actor contract.Actor, request contract.Request) (contract.Result, error)
|
|
}
|
|
|
|
var _ ActBackend = (*gateway.Gateway)(nil)
|
|
|
|
// NewChatToolAdapter returns an adapter for the chats consumer: besides what
|
|
// NewToolAdapter serves, it lists and runs action tools, as the chat's user,
|
|
// with no confirmation. The owner it is given must be an ActBackend. A write,
|
|
// schema or create tool is made at once, not left as a proposal, when the owner
|
|
// is also an Applier: enabling the add-on for the chat is the consent, and the
|
|
// same preview, revision and receipt rules apply.
|
|
func NewChatToolAdapter(b Backend) *ToolAdapter {
|
|
t := &ToolAdapter{backend: b, newID: randomOperationID, actions: true}
|
|
t.apply, _ = b.(Applier)
|
|
return t
|
|
}
|
|
|
|
func randomOperationID() (string, error) {
|
|
var raw [16]byte
|
|
if _, err := rand.Read(raw[:]); err != nil {
|
|
return "", err
|
|
}
|
|
return "t" + hex.EncodeToString(raw[:]), nil
|
|
}
|
|
|
|
var toolName = regexp.MustCompile(`^addon__([a-z][a-z0-9-]{0,63})__([a-z][a-z0-9-]{0,63})$`)
|
|
|
|
// ToolName is the function name of an add-on tool.
|
|
func ToolName(addonID, tool string) string { return Prefix + addonID + "__" + tool }
|
|
|
|
// ParseToolName splits a namespaced name. It accepts nothing else.
|
|
func ParseToolName(name string) (addonID, tool string, ok bool) {
|
|
m := toolName.FindStringSubmatch(name)
|
|
if m == nil || len(name) > MaxNameLength {
|
|
return "", "", false
|
|
}
|
|
return m[1], m[2], true
|
|
}
|
|
|
|
// IsToolName reports whether name is in the namespace reserved for add-on
|
|
// tools. Other tool sources never use it.
|
|
func IsToolName(name string) bool { return strings.HasPrefix(name, Prefix) }
|
|
|
|
func checkActor(a contract.Actor) error {
|
|
if strings.TrimSpace(a.UserID) == "" || strings.TrimSpace(a.CredentialID) == "" || (a.Mode != "named-user" && a.Mode != "local-owner") {
|
|
return gateway.ErrForbidden
|
|
}
|
|
return nil
|
|
}
|
|
|
|
// visible lists the apps whose tools the actor can use now.
|
|
func (t *ToolAdapter) visible(ctx context.Context, actor contract.Actor) ([]apps.App, error) {
|
|
if err := checkActor(actor); err != nil {
|
|
return nil, err
|
|
}
|
|
list, err := t.backend.Apps(ctx, actor)
|
|
if err != nil {
|
|
return nil, gateway.ClassifyCheck(err)
|
|
}
|
|
var out []apps.App
|
|
for _, a := range list.Apps {
|
|
if a.Enabled && a.State == "running" && a.Generation > 0 && len(a.ToolDefinitions) > 0 {
|
|
out = append(out, a)
|
|
}
|
|
}
|
|
return out, nil
|
|
}
|
|
|
|
// Controls returns the host controls the apps list draws for one add-on the
|
|
// actor can see (see contract.EntitledControls), or nil when it is not
|
|
// listed, has no UI or is not entitled to any.
|
|
func (t *ToolAdapter) Controls(ctx context.Context, actor contract.Actor, addonID string) ([]string, error) {
|
|
if err := checkActor(actor); err != nil {
|
|
return nil, err
|
|
}
|
|
list, err := t.backend.Apps(ctx, actor)
|
|
if err != nil {
|
|
return nil, gateway.ClassifyCheck(err)
|
|
}
|
|
for _, a := range list.Apps {
|
|
if a.ID == addonID && a.UI != nil {
|
|
return slices.Clone(a.UI.Controls), nil
|
|
}
|
|
}
|
|
return nil, nil
|
|
}
|
|
|
|
// AddonSkills is the skills of one add-on the actor can see.
|
|
type AddonSkills struct {
|
|
AddonID, Title string
|
|
// InstalledAt is when the add-on was first installed, or empty.
|
|
InstalledAt string
|
|
Skills []contract.SkillDefinition
|
|
// Running is true when the add-on may serve now: enabled and running, as
|
|
// Discover requires for tools.
|
|
Running bool
|
|
}
|
|
|
|
// Skills lists the installed add-ons that ship skills and that the actor can
|
|
// see, running or not. A chat offers the skills of a running one from the copy
|
|
// in its skill layer, and says when a built-in skill serves because the
|
|
// add-on that replaces it is not running.
|
|
func (t *ToolAdapter) Skills(ctx context.Context, actor contract.Actor) ([]AddonSkills, error) {
|
|
if err := checkActor(actor); err != nil {
|
|
return nil, err
|
|
}
|
|
list, err := t.backend.Apps(ctx, actor)
|
|
if err != nil {
|
|
return nil, gateway.ClassifyCheck(err)
|
|
}
|
|
var out []AddonSkills
|
|
for _, a := range list.Apps {
|
|
if len(a.Skills) == 0 {
|
|
continue
|
|
}
|
|
running := a.Enabled && a.State == "running" && a.Generation > 0
|
|
out = append(out, AddonSkills{AddonID: a.ID, Title: a.Title, InstalledAt: a.InstalledAt, Skills: slices.Clone(a.Skills), Running: running})
|
|
}
|
|
slices.SortFunc(out, func(x, y AddonSkills) int { return strings.Compare(x.AddonID, y.AddonID) })
|
|
return out, nil
|
|
}
|
|
|
|
// AddonShadows is one installed add-on that replaces built-in chat tools, as
|
|
// the actor sees it, running or not.
|
|
type AddonShadows struct {
|
|
AddonID, Title string
|
|
// InstalledAt is when the add-on was first installed, or empty.
|
|
InstalledAt string
|
|
// Tools are the built-in chat tools it replaces (bash, web_fetch).
|
|
Tools []string
|
|
// Running is true when the add-on may serve now: enabled and running, as
|
|
// Discover requires.
|
|
Running bool
|
|
}
|
|
|
|
// Shadowers lists the installed add-ons that replace a built-in chat tool and
|
|
// that the actor can see, in any state. A chat uses it to tell a pinned add-on
|
|
// that is stopped (the built-in serves, with a note) from a pin to an add-on
|
|
// that is not installed (the pin is ignored), and Settings lists every add-on
|
|
// an administrator can choose.
|
|
func (t *ToolAdapter) Shadowers(ctx context.Context, actor contract.Actor) ([]AddonShadows, error) {
|
|
if err := checkActor(actor); err != nil {
|
|
return nil, err
|
|
}
|
|
list, err := t.backend.Apps(ctx, actor)
|
|
if err != nil {
|
|
return nil, gateway.ClassifyCheck(err)
|
|
}
|
|
var out []AddonShadows
|
|
for _, a := range list.Apps {
|
|
var names []string
|
|
for _, d := range a.ToolDefinitions {
|
|
if d.Shadows != "" && slices.Contains(a.Tools, d.Name) && contract.ValidateShadow(d) == nil && !slices.Contains(names, d.Shadows) {
|
|
names = append(names, d.Shadows)
|
|
}
|
|
}
|
|
if len(names) == 0 {
|
|
continue
|
|
}
|
|
running := a.Enabled && a.State == "running" && a.Generation > 0
|
|
out = append(out, AddonShadows{AddonID: a.ID, Title: a.Title, InstalledAt: a.InstalledAt, Tools: names, Running: running})
|
|
}
|
|
slices.SortFunc(out, func(x, y AddonShadows) int { return strings.Compare(x.AddonID, y.AddonID) })
|
|
return out, nil
|
|
}
|
|
|
|
func definition(a apps.App, d contract.ToolDefinition) (ToolDefinition, bool) {
|
|
if d.UIOnly {
|
|
return ToolDefinition{}, false // for the add-on's own page, never for a model
|
|
}
|
|
name := ToolName(a.ID, d.Name)
|
|
if _, _, ok := ParseToolName(name); !ok || !slices.Contains(a.Tools, d.Name) {
|
|
return ToolDefinition{}, false
|
|
}
|
|
// The owner validated the manifest at install; it is checked again here
|
|
// because a schema is what a model is told to obey.
|
|
if contract.ValidateToolSchema(d.InputSchema, d.Kind) != nil {
|
|
return ToolDefinition{}, false
|
|
}
|
|
var params map[string]any
|
|
if json.Unmarshal(d.InputSchema, ¶ms) != nil {
|
|
return ToolDefinition{}, false
|
|
}
|
|
def := ToolDefinition{Name: name, AddonID: a.ID, Tool: d.Name, Kind: d.Kind, Description: d.Description, Parameters: params, InstalledAt: a.InstalledAt}
|
|
// Checked again for the same reason as the schema: a manifest that names a
|
|
// tool outside the list, or a shadow of the wrong kind or schema, never
|
|
// shadows it.
|
|
if d.Shadows != "" && contract.ValidateShadow(d) == nil {
|
|
def.Shadows = d.Shadows
|
|
}
|
|
return def, true
|
|
}
|
|
|
|
// Discover returns the tools the actor may offer a model now, in a stable
|
|
// order. A model is never told about a tool it could not call.
|
|
func (t *ToolAdapter) Discover(ctx context.Context, actor contract.Actor) ([]ToolDefinition, error) {
|
|
list, err := t.visible(ctx, actor)
|
|
if err != nil {
|
|
return nil, err
|
|
}
|
|
var out []ToolDefinition
|
|
for _, a := range list {
|
|
for _, d := range a.ToolDefinitions {
|
|
if d.Kind == contract.ToolKindAction && !t.actions {
|
|
continue
|
|
}
|
|
if def, ok := definition(a, d); ok && len(out) < MaxTools {
|
|
out = append(out, def)
|
|
}
|
|
}
|
|
}
|
|
slices.SortFunc(out, func(x, y ToolDefinition) int { return strings.Compare(x.Name, y.Name) })
|
|
return out, nil
|
|
}
|
|
|
|
// Execute runs one tool call as actor. The actor is the authenticated
|
|
// principal of the consumer's request or job; arguments cannot change it.
|
|
func (t *ToolAdapter) Execute(ctx context.Context, actor contract.Actor, name string, arguments json.RawMessage) (ToolResult, error) {
|
|
return t.ExecuteIn(ctx, actor, "", name, arguments)
|
|
}
|
|
|
|
// ChatCall is the chat a tool call comes from: the user whose files the chat
|
|
// uses, as the chats service names them, and the chat's ID. The chat turn
|
|
// builds it from its own record of the chat, never from the model's arguments.
|
|
type ChatCall struct {
|
|
principal, conversation string
|
|
}
|
|
|
|
// NewChatCall returns the chat of a tool call.
|
|
func NewChatCall(principal, conversation string) ChatCall {
|
|
return ChatCall{principal: principal, conversation: conversation}
|
|
}
|
|
|
|
// ExecuteChat runs one tool call of a chat, of any kind. The call is bound to
|
|
// the chat on the host side (hostops.WithBinding): the owner records the chat
|
|
// next to the envelope, so the add-on's workspace operations act with the
|
|
// chat's access, also for a read tool that names no resource. The envelope the
|
|
// add-on receives does not change. The conversation is the chat's ID, used as
|
|
// ExecuteIn uses it.
|
|
func (t *ToolAdapter) ExecuteChat(ctx context.Context, actor contract.Actor, call ChatCall, name string, arguments json.RawMessage) (ToolResult, error) {
|
|
b := hostops.Binding{Principal: call.principal, ChatID: call.conversation}
|
|
if !b.Valid() || !ValidConversationID(call.conversation) {
|
|
return ToolResult{}, ErrInvalidArguments
|
|
}
|
|
return t.execute(hostops.WithBinding(ctx, b), actor, call.conversation, name, arguments)
|
|
}
|
|
|
|
// ExecuteIn runs one tool call of a conversation. The conversation ID comes
|
|
// from the consumer's authenticated request, never from the arguments: it is
|
|
// used only when the call names no resource, to resolve the conversation's
|
|
// selection at the owner. An empty ID means the consumer has no conversation.
|
|
// The chats adapter refuses a conversation here: a chat's call goes through
|
|
// ExecuteChat, so it is never made without its binding.
|
|
func (t *ToolAdapter) ExecuteIn(ctx context.Context, actor contract.Actor, conversationID, name string, arguments json.RawMessage) (ToolResult, error) {
|
|
if t.actions && conversationID != "" {
|
|
return ToolResult{}, ErrInvalidArguments
|
|
}
|
|
return t.execute(ctx, actor, conversationID, name, arguments)
|
|
}
|
|
|
|
func (t *ToolAdapter) execute(ctx context.Context, actor contract.Actor, conversationID, name string, arguments json.RawMessage) (ToolResult, error) {
|
|
if conversationID != "" && !ValidConversationID(conversationID) {
|
|
return ToolResult{}, ErrInvalidArguments
|
|
}
|
|
addonID, tool, ok := ParseToolName(name)
|
|
if !ok {
|
|
return ToolResult{}, ErrUnknownTool
|
|
}
|
|
list, err := t.visible(ctx, actor)
|
|
if err != nil {
|
|
return ToolResult{}, err
|
|
}
|
|
var app apps.App
|
|
var def ToolDefinition
|
|
var found bool
|
|
for _, a := range list {
|
|
if a.ID != addonID {
|
|
continue
|
|
}
|
|
for _, d := range a.ToolDefinitions {
|
|
if d.Name != tool {
|
|
continue
|
|
}
|
|
if d.Kind == contract.ToolKindAction && !t.actions {
|
|
continue // not offered to this consumer, so not there
|
|
}
|
|
if x, ok := definition(a, d); ok {
|
|
app, def, found = a, x, true
|
|
}
|
|
}
|
|
}
|
|
if !found {
|
|
return ToolResult{}, ErrUnknownTool
|
|
}
|
|
resource, body, err := toolargs.Bind(def.Tool, def.Parameters, arguments, conversationID != "")
|
|
if err != nil {
|
|
return ToolResult{}, err
|
|
}
|
|
if resource == "" && conversationID != "" && requiresResource(def) {
|
|
sel, ok := t.backend.(Selector)
|
|
if !ok {
|
|
return ToolResult{}, ErrInvalidArguments
|
|
}
|
|
id, err := sel.ResolveSelection(ctx, actor, conversationID, app.ID)
|
|
switch {
|
|
case errors.Is(err, gateway.ErrNotSelected):
|
|
return ToolResult{Kind: ResultError, Tool: name, Code: CodeSelectResource, Note: SelectNote}, nil
|
|
case err != nil:
|
|
// A revoked, deleted or foreign reference is the denial of an
|
|
// unknown resource, so the model reads the same words as for a
|
|
// resource it named that does not exist. An outage stays an
|
|
// outage.
|
|
return refusedResult(name, err)
|
|
case !toolargs.ValidResourceID(id):
|
|
return ToolResult{}, gateway.ErrForbidden
|
|
}
|
|
resource = id
|
|
}
|
|
op, err := t.newID()
|
|
if err != nil {
|
|
return ToolResult{}, gateway.ErrUnavailable
|
|
}
|
|
request := contract.Request{AddonID: app.ID, ResourceID: resource, OperationID: op, Generation: app.Generation, Arguments: body}
|
|
if def.Kind == contract.ToolKindAction {
|
|
ab, ok := t.backend.(ActBackend)
|
|
if !ok {
|
|
return ToolResult{}, gateway.ErrUnavailable
|
|
}
|
|
request.Action = "act"
|
|
// An action works for one chat. The conversation comes from the chat's
|
|
// own authenticated turn and rides in ResourceID, mapped to a valid resource ID; the model cannot name
|
|
// it, because no action schema has that property. It scopes the
|
|
// add-on's state and is never authority.
|
|
if conversationID == "" {
|
|
return ToolResult{}, ErrInvalidArguments
|
|
}
|
|
request.ResourceID = toolargs.ActionResourceID(conversationID)
|
|
out, err := ab.Act(ctx, actor, request)
|
|
if err != nil {
|
|
return refusedResult(name, err)
|
|
}
|
|
return readResult(name, out)
|
|
}
|
|
if def.Kind == contract.ToolKindRead {
|
|
request.Action = "read"
|
|
out, err := t.backend.Dispatch(ctx, actor, request)
|
|
if err != nil {
|
|
return refusedResult(name, err)
|
|
}
|
|
return readResult(name, out)
|
|
}
|
|
request.Action = map[string]string{contract.ToolKindWrite: "write", contract.ToolKindSchema: "schema", contract.ToolKindCreate: "create"}[def.Kind]
|
|
p, err := t.backend.Propose(ctx, actor, request)
|
|
if err != nil {
|
|
return refusedResult(name, err)
|
|
}
|
|
if t.apply != nil {
|
|
return t.applyNow(ctx, actor, name, p)
|
|
}
|
|
ref := ProposalRef{ID: p.ID, AddonID: p.AddonID, ResourceID: p.ResourceID, Action: p.Action, Digest: p.Digest,
|
|
State: string(p.State), Count: p.Effects.Count, ExpiresAt: p.ExpiresAt}
|
|
if len(p.Effects.Sample) <= MaxSummaryBytes {
|
|
ref.Summary = p.Effects.Sample
|
|
}
|
|
return ToolResult{Kind: ResultProposal, Tool: name, Proposal: &ref, Note: ProposalNote}, nil
|
|
}
|
|
|
|
// applyNow confirms the proposal the adapter has just stored for the actor. A
|
|
// failure that is certain withdraws the proposal, so nothing waits for a
|
|
// browser; an unknown outcome is left alone and reported, never repeated.
|
|
func (t *ToolAdapter) applyNow(ctx context.Context, actor contract.Actor, name string, p gateway.Proposal) (ToolResult, error) {
|
|
done, err := t.apply.ConfirmProposal(ctx, actor, p.ID, p.Digest)
|
|
if err != nil {
|
|
var unknown *gateway.OutcomeUnknown
|
|
var unavailable *gateway.ProposalUnavailable
|
|
if !errors.As(err, &unknown) && !errors.As(err, &unavailable) {
|
|
// The caller's context may be over; the withdrawal must still run.
|
|
_, _ = t.apply.CancelProposal(context.WithoutCancel(ctx), actor, p.ID)
|
|
}
|
|
return refusedResult(name, err)
|
|
}
|
|
if done.State != gateway.ProposalApplied {
|
|
// The add-on rejected it at the apply: the data moved or it cannot do
|
|
// this. Nothing changed, so the model corrects or asks again.
|
|
return ToolResult{}, gateway.ErrStale
|
|
}
|
|
ref := AppliedRef{ID: p.ID, AddonID: p.AddonID, ResourceID: p.ResourceID, Action: p.Action, Count: p.Effects.Count}
|
|
if len(p.Effects.Sample) <= MaxAppliedBytes {
|
|
ref.Summary = p.Effects.Sample
|
|
}
|
|
if done.Receipt != nil && len(done.Receipt.Result.Payload) <= MaxAppliedBytes {
|
|
ref.Result = done.Receipt.Result.Payload
|
|
}
|
|
note := AppliedNote
|
|
n, _ := contract.ParseUndoNote(receiptPayload(done))
|
|
switch {
|
|
case n.Available:
|
|
ref.Undoable, ref.ChangeID, ref.Undo = true, n.ID, n.Summary
|
|
note = UndoableNote
|
|
case n.Reason != "":
|
|
ref.Reason = n.Reason
|
|
default:
|
|
ref.Reason = noUndoReason
|
|
}
|
|
return ToolResult{Kind: ResultApplied, Tool: name, Applied: &ref, Note: note}, nil
|
|
}
|
|
|
|
func receiptPayload(p gateway.Proposal) json.RawMessage {
|
|
if p.Receipt == nil {
|
|
return nil
|
|
}
|
|
return p.Receipt.Result.Payload
|
|
}
|
|
|
|
// refusedResult turns the add-on's own refusal, a missing permission and an
|
|
// unreachable resource into a result the model can act
|
|
// on. Every other error, an outage and an unknown outcome included, passes
|
|
// through unchanged.
|
|
func refusedResult(name string, err error) (ToolResult, error) {
|
|
switch {
|
|
case errors.Is(err, gateway.ErrNotPermitted):
|
|
return ToolResult{Kind: ResultError, Tool: name, Code: CodeNotPermitted, Note: NotPermittedNote}, nil
|
|
case errors.Is(err, gateway.ErrNotSent):
|
|
return ToolResult{Kind: ResultError, Tool: name, Code: CodeNotRunning, Note: NotRunningNote}, nil
|
|
case errors.Is(err, gateway.ErrResourceUnreachable):
|
|
return ToolResult{Kind: ResultError, Tool: name, Code: CodeResourceUnreachable, Note: ResourceUnreachableNote}, nil
|
|
}
|
|
if errors.Is(err, gateway.ErrInvalidRequest) || errors.Is(err, contract.ErrRefused) {
|
|
res := ToolResult{Kind: ResultError, Tool: name, Code: CodeInvalidRequest, Note: InvalidNote, Message: refusalMessage(err)}
|
|
if res.Message != "" {
|
|
res.Note = ReasonedNote
|
|
}
|
|
return res, nil
|
|
}
|
|
return ToolResult{}, err
|
|
}
|
|
|
|
// refusalMessage is the reason in the add-on's refusal, unless it is only the
|
|
// class every refusal has.
|
|
func refusalMessage(err error) string {
|
|
var r *addonruntime.Refusal
|
|
if errors.As(err, &r) && r.Reason != "" && r.Reason != "invalid request" {
|
|
return r.Reason
|
|
}
|
|
return ""
|
|
}
|
|
|
|
// requiresResource reports a tool whose schema requires the resource.
|
|
func requiresResource(def ToolDefinition) bool {
|
|
props, _ := def.Parameters["properties"].(map[string]any)
|
|
if _, ok := props[contract.ResourceArgument]; !ok {
|
|
return false
|
|
}
|
|
req, _ := def.Parameters["required"].([]any)
|
|
for _, r := range req {
|
|
if s, _ := r.(string); s == contract.ResourceArgument {
|
|
return true
|
|
}
|
|
}
|
|
return false
|
|
}
|
|
|
|
// ValidConversationID reports whether id has the shape of a conversation
|
|
// identifier: the namespace of one user's selections.
|
|
func ValidConversationID(id string) bool { return toolargs.ValidConversationID(id) }
|
|
|
|
func readResult(name string, out contract.Result) (ToolResult, error) {
|
|
if len(out.Outputs) > 0 {
|
|
refs := make([]ArtifactRef, 0, len(out.Outputs))
|
|
for _, o := range out.Outputs {
|
|
refs = append(refs, ArtifactRef{ID: o.Handle, Name: o.Name, MediaType: o.MediaType, Size: o.Size})
|
|
}
|
|
return ToolResult{Kind: ResultArtifact, Tool: name, Artifacts: refs}, nil
|
|
}
|
|
if len(out.Payload) > MaxResultBytes {
|
|
return ToolResult{}, ErrResultTooLarge
|
|
}
|
|
return ToolResult{Kind: ResultData, Tool: name, Result: out.Payload}, nil
|
|
}
|
|
|
|
// JSON is the form of a result in a tool message and in chat.
|
|
func (r ToolResult) JSON() string {
|
|
b, err := json.Marshal(r)
|
|
if err != nil {
|
|
return `{"kind":"error"}`
|
|
}
|
|
return string(b)
|
|
}
|
|
|
|
// String describes a definition for logs.
|
|
func (d ToolDefinition) String() string { return fmt.Sprintf("%s (%s)", d.Name, d.Kind) }
|