From 61c54dc833646c273d84fe18919efbef157dc27a Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Tue, 3 Nov 2026 10:36:52 +0000 Subject: [PATCH] refactor(studio): word the command provider text without naming an add-on The prompt, the Tools menu reasons, the network error texts, the CLI help, the API instructions and the assistant tool descriptions said "Sandbox" for the add-on that runs commands. Core must not know that name. The reason a chat has no commands now uses the title the provider declares ("the Zeta add-on is off for this chat") or, when none is installed, says "the add-on that runs commands". Text that has no provider in hand speaks of the network of commands or of an add-on that isolates them. Assisted-by: Claude Code:claude-sonnet-5-5 Signed-off-by: Ettore Di Giacinto --- core/application/studio_egress_settings.go | 2 +- core/application/studio_service.go | 8 ++++---- core/application/studio_web.go | 2 +- core/application/studio_web_test.go | 2 +- core/cli/run.go | 2 +- core/http/endpoints/localai/api_instructions.go | 2 +- core/http/endpoints/studio/studio.go | 2 +- core/services/studio/capabilities.go | 14 ++++++++++++-- core/services/studio/commandaccess_test.go | 2 +- core/services/studio/egress/egress.go | 10 +++++----- core/services/studio/egress/egress_test.go | 2 +- core/services/studio/egresscards.go | 2 +- core/services/studio/egresscheck.go | 2 +- core/services/studio/hostbash.go | 16 ++++++++++------ core/services/studio/hostexec/hostexec.go | 2 +- core/services/studio/toolgroups.go | 8 ++++---- docs/content/features/chats.md | 2 +- docs/content/features/runtime-settings.md | 4 ++-- pkg/egresspolicy/policy.go | 4 ++-- pkg/mcp/localaitools/prompts/20_tools.md | 6 +++--- .../prompts/skills/manage_sandbox_network.md | 10 +++++----- pkg/mcp/localaitools/tools_chat_tools.go | 10 +++++----- 22 files changed, 64 insertions(+), 50 deletions(-) diff --git a/core/application/studio_egress_settings.go b/core/application/studio_egress_settings.go index 9346c3c8e0..98f462a2da 100644 --- a/core/application/studio_egress_settings.go +++ b/core/application/studio_egress_settings.go @@ -48,7 +48,7 @@ func (l *lastGood[T]) get(raw string) T { } if l.logged != raw { l.logged = raw - xlog.Warn("Chats: a Sandbox network setting is not valid; the last valid value stays in force", "setting", l.name, "kept_last_valid", l.ok, "error", err) + xlog.Warn("Chats: a command network setting is not valid; the last valid value stays in force", "setting", l.name, "kept_last_valid", l.ok, "error", err) } return keep } diff --git a/core/application/studio_service.go b/core/application/studio_service.go index c7cc4b0fb1..0b137ed411 100644 --- a/core/application/studio_service.go +++ b/core/application/studio_service.go @@ -499,7 +499,7 @@ func (a *Application) initStudioEgressLists() { }, nil) } -// studioEgressAudit opens the audit of the Sandbox network requests, beside +// studioEgressAudit opens the audit of the command network requests, beside // the audit of the commands run on this machine. func (a *Application) studioEgressAudit() audit.Store { var ( @@ -515,7 +515,7 @@ func (a *Application) studioEgressAudit() audit.Store { st, err = audit.NewJSON("") } if err != nil { - xlog.Warn("Chats: the audit of the Sandbox network is kept in memory", "error", err) + xlog.Warn("Chats: the audit of the command network is kept in memory", "error", err) st, _ = audit.NewJSON("") } return st @@ -532,9 +532,9 @@ func (a *Application) startStudioEgressPrune(svc *studio.Service) { prune := func() { n, err := svc.PruneEgressAudit(ctx) if err != nil { - xlog.Warn("Chats: could not prune the Sandbox network audit", "error", err) + xlog.Warn("Chats: could not prune the command network audit", "error", err) } else if n > 0 { - xlog.Info("Chats: pruned the Sandbox network audit", "lines", n) + xlog.Info("Chats: pruned the command network audit", "lines", n) } n, err = svc.PruneHostExecAudit(ctx) if err != nil { diff --git a/core/application/studio_web.go b/core/application/studio_web.go index 56ebd967ad..89b507374e 100644 --- a/core/application/studio_web.go +++ b/core/application/studio_web.go @@ -20,7 +20,7 @@ import ( // webSettingsHint is where an administrator fixes the search. It is part of // the error a user reads when no provider works, after what each provider did. -const webSettingsHint = "an administrator can set a SearXNG instance in Settings > Tools, or install the Web add-on for search providers with a key from Add-ons" +const webSettingsHint = "an administrator can set a SearXNG instance in Settings > Tools, or install an add-on that provides search providers with a key from Add-ons" // studioWeb serves the built-in web tools of the chats. It reads the runtime // settings at each call and builds the fetch client and the searcher again diff --git a/core/application/studio_web_test.go b/core/application/studio_web_test.go index 241f85b984..4f2922c83b 100644 --- a/core/application/studio_web_test.go +++ b/core/application/studio_web_test.go @@ -115,7 +115,7 @@ var _ = Describe("the chats' built-in web tools", func() { cfg.ChatsWebSearchProviders = "duckduckgo,bing_html" _, err := w.Search(context.Background(), "alice", json.RawMessage(`{"query":"localai"}`)) Expect(err).To(MatchError("no search provider works. Tried duckduckgo: challenged by a bot check; bing_html: blocked this server (429 Too Many Requests). " + - "An administrator can set a SearXNG instance in Settings > Tools, or install the Web add-on for search providers with a key from Add-ons.")) + "An administrator can set a SearXNG instance in Settings > Tools, or install an add-on that provides search providers with a key from Add-ons.")) _, _, _, attempts, err := w.TestSearch(context.Background(), "root", "localai") Expect(err).To(MatchError(ContainSubstring("no search provider works. Tried duckduckgo: challenged"))) Expect(attempts).To(HaveLen(2)) diff --git a/core/cli/run.go b/core/cli/run.go index aa5bbc4b99..a41e672284 100644 --- a/core/cli/run.go +++ b/core/cli/run.go @@ -164,7 +164,7 @@ type RunCMD struct { // LocalAI Assistant chat modality (in-process admin MCP server) DisableLocalAIAssistant bool `env:"LOCALAI_DISABLE_ASSISTANT" default:"false" help:"Disable the LocalAI Assistant chat modality (in-process admin MCP server)" group:"assistant"` DisableSharedPages bool `env:"LOCALAI_DISABLE_SHARED_PAGES" default:"false" help:"Turn off the pages of shared folders (they can be switched on again in the runtime settings)" group:"assistant"` - ChatsHostExec string `env:"LOCALAI_CHATS_HOST_EXEC" default:"" enum:",off,ask,on" help:"Who gets the chats' built-in bash, which runs commands on this machine with no isolation and with its network: off, ask (administrators, who allow each command) or on. Empty: off with accounts, ask without. The Sandbox add-on replaces it with isolated commands" group:"assistant"` + ChatsHostExec string `env:"LOCALAI_CHATS_HOST_EXEC" default:"" enum:",off,ask,on" help:"Who gets the chats' built-in bash, which runs commands on this machine with no isolation and with its network: off, ask (administrators, who allow each command) or on. Empty: off with accounts, ask without. An add-on that runs commands in isolation replaces it" group:"assistant"` // Removed agent, job and skill options: accepted and ignored. RemovedAgentOptions `embed:""` diff --git a/core/http/endpoints/localai/api_instructions.go b/core/http/endpoints/localai/api_instructions.go index 5f032bd469..feafb1706f 100644 --- a/core/http/endpoints/localai/api_instructions.go +++ b/core/http/endpoints/localai/api_instructions.go @@ -28,7 +28,7 @@ var instructionDefs = []instructionDef{ {Name: "agent-jobs", Description: "Agent tasks and jobs: saved prompt templates run in the background, with webhooks", Tags: []string{"agent-jobs"}, Intro: "A task is a prompt template ({{.name}} parameters) run by a model or a saved agent (agent_id); a job is one run of it, a background chat of its owner with origin job. POST /api/agent/tasks creates a task {name, model, agent_id, prompt, enabled, webhooks [{url, method, headers, payload_template}]}; GET, PUT and DELETE /api/agent/tasks/{id} read, replace and delete it; header values are never returned (sent back as [hidden] they keep their value). POST /api/agent/jobs/execute {task_id, parameters, images, videos, audios, files} or POST /api/agent/tasks/{name}/execute {parameters} starts a job and answers 201 {job_id, status, url} at once; attachments are base64 data URIs, an address is never fetched. GET /api/agent/jobs/{id} gives status (pending, running, completed, failed, cancelled), result, error, traces and the webhook delivery; GET /api/agent/jobs lists newest first (task_id, status, limit); POST .../jobs/{id}/cancel stops one, POST .../jobs/{id}/rerun runs it again, DELETE removes it with its chat. cron and multimedia_sources on a task are refused: schedule a saved agent with a trigger. A webhook to a private address is refused unless an administrator allows it. Needs the mcp_jobs feature (off by default); ?all_users=true gives an administrator a read-only view of every user's tasks and jobs."}, {Name: "collections", Description: "Collections: the knowledge base of documents the chats can search, with files and followed URLs as sources", Tags: []string{"collections"}, Intro: "A collection is a set of files the server cuts into passages and embeds. GET and POST /api/collections list and create (POST {name}) the collections of the user; POST /api/collections/{name}/upload (multipart field file) adds a file; GET .../entries, .../entries/{entry} and .../entries-raw/{entry} read them; POST .../search {query, max_results} returns the best passages (a number above the passages stored returns all of them); DELETE .../entry/delete {entry} removes one; POST .../reset removes every entry and keeps the collection and its sources; GET, POST and DELETE .../sources follow a URL. Names with special characters must be URL-encoded. Each user sees only their own collections. The routes need the collections feature (off by default for a user); the service can be turned off with LOCALAI_DISABLE_COLLECTIONS. A saved agent can search a collection when it is granted in the agent's collections list. The deprecated path /api/agents/collections serves the same store with a Deprecation header."}, {Name: "workspace", Description: "A live feed of the changes to your files, whoever made them", Tags: []string{"workspace"}, Intro: "GET /api/workspace/events streams server-sent events: a change event {revision, paths, kinds} when files in your home folder change, from any client, chat, trigger, connector or frontend. Paths are inside your home, without a leading slash; kinds are the kinds of the change sets (user, agent, upload, undo). Changes close together come as one event, about once a second at most. A resync event {revision} means some changes were left out: read again what you show. The event id is the revision; send it back as Last-Event-ID or ?after= to resume, otherwise the stream starts from now. A comment line comes every 25 seconds. You see only paths you may read. At most 8 streams per user (429 after). Needs the chats feature; 409 files_off when the server has no files."}, - {Name: "chats", Description: "Chats the server keeps: steering, sub-agents and live events", Tags: []string{"chats"}, Intro: "POST /api/chats starts a chat with a model; PATCH /api/chats/{id} {title, model, settings} renames it (1 to 80 characters), moves it to another model (history stays) or sets its settings {system_prompt, temperature, top_p, top_k, reasoning_effort, context_size}, which apply from the next turn (a new title or model needs an idle chat: 409 otherwise). POST .../{id}/regenerate answers the last message again, POST .../{id}/messages/{seq}/edit {text} replaces one of your messages and runs again from it (later lines are removed), POST .../{id}/fork {from_seq, title} copies a chat up to a line into a new chat, GET /api/chats/search?q= finds chats by title or text, GET .../{id}/export?format=markdown|json returns a chat as a file and POST /api/chats/import {chat, model} stores a JSON export as a new chat. Events also carry usage {used, limit, completion, tokens_per_second, model, node, prompt_ms} after each model request, for a context meter (node only when the server exposes the node header, prompt_ms only when the backend reports timings). Sub-agents: GET /api/chats/{id}/agents lists the sub-agent runs of a chat with running, last_turn and the background limit (from the shared store), GET .../{id}/agents/{agent_id}/messages reads one run's transcript and POST .../{id}/agents/{agent_id}/stop stops it; sub_agent_started and sub_agent_done events mark them in the parent's stream. A chat that PUT .../{id}/builtins {on: [\"saved_agents\"]} switched on (off by default; needs the agents feature and the chats_saved_agents setting) also gets list_agents and the agent argument of spawn_agent (a saved agent's id or name): the sub-agent then runs with that agent's instructions, model and grants. POST .../{id}/messages sends a message: with no turn running it starts one; with a turn running it waits (started false, pending_id) and reaches the model, together with any others and in order, at the model's next request. GET .../{id} lists the waiting messages; PATCH and DELETE .../{id}/pending/{pid} edit or cancel one until it is delivered (409 after). After a stop or a failed turn the waiting messages stay; POST .../{id}/send-now starts a turn from them and POST .../{id}/stop ends a running turn. Goals: PUT .../{id}/goal {text} sets a goal for the chat (it replaces the one it had, returned as replaced) and starts a turn on it when none runs; while the goal is active every turn's prompt carries it, the model gets goal_done {summary} and goal_blocked {reason}, and when a turn ends by itself the server starts the next one, until the goal is done or blocked, you stop it (POST .../{id}/stop pauses the goal), or chats_goal_max_turns (20 by default) automatic turns or chats_goal_max_steps (400) model steps pause it. Your messages still steer it: they go first. GET .../{id}/goal reads it {text, state active|paused|done|blocked, paused_by user|turn_limit|step_limit|error|interrupted, note, turns, max_turns, steps, max_steps}, DELETE .../{id}/goal clears it and POST .../{id}/goal/resume resumes a paused or blocked one with new counts; GET .../{id} carries it as goal, a goal event says it changed, and the transcript has goal lines (role goal, goal_event set|replaced|continue|paused|resumed|done|blocked|cleared). A chat that a trigger, a connector, a job or a page started, and a sub-agent run, cannot have a goal. A turn whose tool loop reaches the step limit (the runtime setting chats_max_iterations, 40 by default, or the model's agent.max_iterations) ends with last_turn paused after a paused event {steps}: the model answered from what it had, and a new message (for example \"Continue\") goes on. GET .../{id}/messages reads the transcript (a user line has text, the words typed, and attachments [{path, name, size, mime, version, missing}], the files it carried, with path inside your home for the files API; a waiting message has the same two fields; the model still gets the paths of the files with the message) and GET .../{id}/events streams live server-sent events, so read the transcript first. A chat is named after its first message. A conversation belongs to its user; another user's id is always 404. POST /api/chats/import/browser takes the chats the old chat page kept in the browser (the value of localStorage localai_chats_data) and stores them as yours; a chat that is there already is skipped. Needs the chats feature, which is on by default. Saved agents need the agents feature, triggers the triggers feature and connectors the connectors feature; all three are off by default for a user and an administrator grants them (an administrator has them all). The server can switch the chats off (LOCALAI_DISABLE_CHATS: every /api/chats path then answers 404 chats_off), and the triggers or the connectors alone (LOCALAI_DISABLE_TRIGGERS, LOCALAI_DISABLE_CONNECTORS: their routes answer 409 triggers_off or connectors_off); GET /api/features says what runs. Your files: GET /api/chats/files?path= lists a folder of your workspace (paths are inside your home, \"/\"), GET and PUT /api/chats/files/content?path= download and upload a file (a second upload that does not name the version it started from keeps both files and reports conflict_of), POST .../files/folders and .../files/move create and rename, DELETE .../files?path= moves to the Trash, GET .../files/trash lists deletions (each with files, folders and bytes, and totals for the whole Trash) and POST .../files/undo {rev} restores one, DELETE .../files/trash empties the Trash for good and DELETE .../files/trash/{rev} deletes one entry for good (neither can be undone; they touch only your own Trash and the agent tools never do this), GET .../files/history lists changes, GET .../files/search?q= searches names, text files and the text of PDF, Word, Excel and PowerPoint files (a document hit has document, page, sheet or slide; indexing counts documents still being read), and GET .../files/preview?path= reads a .xlsx, .xlsm, .csv, .tsv, .docx or .pptx file of up to 20 MiB for a preview (kind table: sheets of at most 200 rows by 30 columns with total_rows and total_cols; kind document: headings, list items, paragraphs and tables {type table, rows}; kind slides: titles, text and notes; 415 for another type). POST .../{id}/messages also takes multipart/form-data (text and files) to attach files (with a turn running the files are saved at once and the message waits with their paths): images go to a vision model inside the message (image_url parts; other models get the path and describe_image), videos to a model that takes video, and the text of PDF, Word, Excel, PowerPoint and EPUB files is added to the message (the model reads the rest with read_document). Skills: GET /api/chats/skills?chat= lists the skills of the five layers (folder, personal, shared, addon, builtin; an addon skill names its add-on in addon and addon_title) with enabled and shadowed, POST creates one {layer personal|shared, name, description, body} (shared needs an administrator), GET PUT DELETE .../skills/{layer}/{name} read, change and delete (to the Trash), PUT /api/chats/{id}/skills {off} switches skills off for one chat. Well-known files: GET and PUT /api/chats/wellknown/{name} (persona, user, shortcuts, home, ui, or widget-data with ?path=) read and change the files of your home that set the assistant's persona, your profile, the composer shortcuts, the Home widgets and the look. A read is validated against the JSON Schema at .../wellknown/{name}/schema and falls back to the last valid version (fallback, errors); a write {values, replace} merges the keys it sends (null removes one), takes the version you read in If-Match (409 with current when the file changed) and is refused with errors when the result is invalid; POST .../wellknown/{name}/revert restores the previous valid version as a new change, or the version {rev} that GET .../wellknown/{name}/versions lists (newest first, with who wrote it and in which chat). A checkpoint line of a transcript carries rev, the change set of the turn, and lists the paths it changed. Add-ons: GET /api/chats/{id}/addons lists the add-ons whose tools you may use, each with its switch for that chat, and PUT /api/chats/{id}/addons {off: [ids]} switches the tools of add-ons off for one chat. Commands: a chat runs commands with bash, served by the Sandbox add-on (isolated) or, when no Sandbox serves it, by the built-in bash directly on this machine with no isolation and with its network; the add-on list says which (commands_provider, commands_isolation, commands_consent, commands_fallback). With chats_host_exec ask, each command waits: a host_exec_consent event carries {ids: [id], text: command} and POST /api/chats/{id}/host-exec/consent {id, decision: once|deny} answers it (once needs an administrator). Administrators: GET /api/chats/admin/tools lists the built-in tools an add-on may replace (Settings > Tools; change them with POST /api/settings chats_host_exec and chats_tool_providers) and GET /api/chats/admin/host-exec/events?limit= reads the audit of the commands run on this machine. Network of the Sandbox commands: the guest has no network device and reaches HTTP and HTTPS only through a proxy that asks the server about each connection. GET /api/chats/{id}/egress returns {preset, ceiling, effective, applies, applies_reason, addon, registries, rules, cards} (applies is false when commands run on this machine, which has the server's network; addon is the add-on that runs the commands and draws the chat's network controls), PUT .../{id}/egress {preset: off|registries|all} sets the chat's preset (400 egress_above_ceiling above the administrator's chats_egress_ceiling), DELETE .../{id}/egress/rules/{host}/{port} removes an allow or deny rule, an egress_consent event {ids: [card id], text: host:port} asks for a host the chat does not allow (the command waits up to 60 seconds) and POST .../{id}/egress/consent {id, decision: once|chat|deny} answers it (allowing a host inside your network needs an administrator), and egress_card events say that the chat's network changed. Administrators: GET /api/chats/admin/egress reads the chats_egress_* settings in force, the registries and the counts of the last 24 hours, and GET /api/chats/admin/egress/events?limit=&user=&chat=&verdict=&host= reads the audit. Saved agents: GET and POST /api/chats/agents, GET PUT DELETE .../agents/{id}: an agent is {name, description, instructions, model, mcp_servers, addons, collections, skills, network, folder}; folder {path, mode read|write} gives it one folder of your files (\"/\" is all of them; not LocalAI, Chats or a shared folder; 400 otherwise), kept by the folder itself so a rename or move is followed, shown back as {path, name, mode, state ok|missing|unset}; a write without folder keeps it and folder {path: \"\"} clears it; network (off, registries or all; off by default) is the network of the Sandbox commands of its trigger and connector runs, capped by chats_egress_ceiling, which never show a card; the lists are exact grants (an empty list grants nothing) and a chat gets only what you may use at that moment. POST /api/chats {agent_id} starts a chat with one (the agent's model replaces model when it has one). GET .../agents/{id}/export returns the definition as a JSON file (version 1, kind localai-agent; version 2 with folder {path, mode} for an agent with a folder, which a server that knows only version 1 refuses), POST .../agents/import takes that file (JSON body or multipart file field) and saves a new agent (a taken name gets a number, an unavailable model is dropped, a folder you do not have leaves the agent unset until you choose one; warnings say so), GET .../agents/templates lists starter agents and POST .../agents/templates/{id}/create saves one, GET .../agents/{id}/runs lists the chats that ran with the agent (yours, trigger runs, connector runs) with last_turn and counts. Inbox: GET /api/chats/notifications?unread=1 lists the notifications of your trigger runs (kind run_ended, run_failed or needs_attention) with the unread count, GET .../notifications/count counts them, POST .../notifications/read {ids} or {all: true} marks them read, DELETE .../notifications {ids} removes some, or {all: true} empties your inbox ({all: true, read_only: true} removes only the read ones; the answer has deleted and the unread count left), the list also gives total (everything kept, since limit, at most 500, can cut the list), and GET .../notifications/events streams new ones as server-sent events plus a notifications_changed event when notifications were read or deleted (from any tab or frontend), after which a client reads the list again. A user only ever reaches their own notifications. Opening a chat (GET /api/chats/{id}) marks its notifications read. Triggers: GET and POST /api/chats/triggers, GET PUT DELETE .../triggers/{id}, POST .../{id}/run (start now), .../{id}/enable and .../{id}/disable, GET .../{id}/runs, GET .../triggers/preview?when=&tz= (next times of a schedule). A trigger is {name, prompt, kind schedule|file, schedule + time_zone, or folder + quiet_seconds, daily_cap, enabled, agent_id, model, source_chat_id}: it starts a chat as you by itself, on a schedule (\"daily 08:00\", \"weekdays 09:30\", \"weekly mon,thu 09:30\", \"monthly 15 08:00\", \"once 2026-12-24 18:00\" or five cron fields) or when a file arrives in the folder; a chat it starts has origin trigger. A trigger also has plan {reads, writes, widget} (what a run reads, the file it rewrites and the Home widget that shows it), cost {estimated_tokens, average_tokens, runs, max_runs_per_day, remote} and last_done, and each run its tokens; a file trigger waits min_gap_seconds (60 by default) after a run before a file that changed again starts another. The four trigger tools (propose_trigger, list_triggers, update_trigger, delete_trigger) are the built-in tool group triggers: on in a chat a person starts, switched together with PUT .../{id}/builtins {off: [\"triggers\"]}, listed in GET .../{id}/tools and GET .../draft/tools with usable and reason (not usable in a run a trigger or connector started, for a user without the triggers feature; not listed when the server runs no triggers), and never given to a sub-agent. A model can propose a trigger in a chat (propose_trigger; a schedule from a chat runs at most once an hour); GET .../triggers/proposals?chat= lists them, PUT .../triggers/proposals/{id} edits one (it stays a proposal), POST .../triggers/proposals/{id}/confirm {time_zone} turns one into a trigger that is on, DELETE dismisses it (the answer is kept: GET .../triggers/proposals/{id} returns {state pending|accepted|declined|undone, trigger, answered_at, can_undo, undo_blocked}, POST .../undo takes an accepted one back unless the trigger ran or was edited since (409 says why) and POST .../reopen restores a declined or undone one); the chat carries a proposal as a card {kind trigger_proposal, id} on the tool line (tool_end event and transcript) and as a trigger_proposed event. A model can also ask to change a trigger of yours (list_triggers gives each a ref; update_trigger edits, pauses or resumes, delete_trigger deletes): an edit or a delete waits for you, and a pause or a resume applies at once; the chat carries it as a card {kind trigger_change, id}. GET .../triggers/changes/{id} returns {id, op update|delete|pause|resume, state pending|applied|dismissed|undone, trigger_id, before, after, fields, answered_at, stale, can_undo, undo_blocked, last_run}, POST .../changes/{id}/apply makes it (409 when the trigger changed since), DELETE dismisses it and POST .../changes/{id}/undo puts the trigger back as it was, for a day after it applied (a deleted trigger comes back with its id, without its run history). Proposed changes: a model asks to change your memory or an agent profile with propose_change {kind memory|profile, scope user|agent|channel, target, content, summary} (in the built-in tool group changes; revert_change {id} undoes an applied one). Nothing is written until you confirm. GET /api/chats/changes?status= lists the proposals (id, kind, scope, target, summary, content, source {kind, id, chat}, status pending|applied|dismissed|expired|reverted|stale, rev), GET .../changes/{id} reads one, POST .../changes/{id}/confirm writes it as one change set, or with a body {content} your own text in its place (409 when the file changed since, the proposal expired after 24 hours or it was answered), POST .../changes/{id}/dismiss answers no, POST .../changes/{id}/undo restores the file (409 when it was edited since) and GET .../changes/audit lists who proposed, confirmed or reverted what, with a hash and never the text. GET /api/chats/context-files lists the notes the host puts in the prompt (limits, and groups of {source, scope, key, max_bytes, max_lines, files}) for the Memory tab of Your settings; it only reads. At most 10 proposals wait per user and 5 are made per hour per agent. A chat that runs a saved agent cannot propose until the agent is granted it. Browser push: GET /api/chats/push/key returns the server's VAPID public key, POST /api/chats/push/subscribe takes a browser PushSubscription {endpoint, keys: {p256dh, auth}} (an https endpoint on a public address) and DELETE .../push/subscribe {endpoint} removes it; a notification is then pushed with its title and link only. These answer 409 push_off when the server keeps nothing across a restart. Conversion: at start the server converts the old chat page, agents, tasks, skills and Telegram connectors; GET /api/chats/conversion lists what happened to your items (kind, name, status converted|skipped|failed|dropped, reason) and gives an administrator the totals. Converted triggers and connectors are switched off. Connectors: GET /api/chats/connectors/kinds lists the platforms that an installed add-on serves (telegram comes with the Telegram add-on), GET and POST /api/chats/connectors, GET PUT DELETE .../connectors/{id}, POST .../{id}/enable, .../disable and .../test (asks Telegram who the bot is), GET .../{id}/senders (who wrote to the bot) and POST .../{id}/senders/{sender}/allow. A binding is {kind (the platform, telegram when empty; set at create only), name, token (write-only, sealed, never returned; has_token says it is stored), agent_id (required: an agent of yours that names a model), enabled, accept_any, allow [chat IDs, user IDs or @usernames], notify_chat}: a person who messages the Telegram bot talks to that agent in a conversation of their own, as you, with only the agent's grants. The allowlist is empty at first, so nobody is accepted; a sender who is not accepted is ignored and logged. accept_any lets anyone who can message the bot use the agent; the create or update that turns it on must also send confirm_accept_any: \"accept any message\" (else 400). Files and skills answer 409 with the reason when the server has no data path. Administrators: GET /api/chats/admin/agents, .../admin/triggers and .../admin/connectors list what every user has, each with its owner and never a token or instructions; GET .../admin/triggers/{id}/runs lists the runs of a trigger, POST .../admin/triggers/{id}/disable and .../admin/connectors/{id}/disable switch one off, and DELETE .../admin/agents/{id}, .../admin/triggers/{id} and .../admin/connectors/{id} remove one. No MCP tool maps to these routes: they are the user's own chat and files, not administration. GET POST /api/chats/mcp-connectors, GET PUT DELETE /api/chats/mcp-connectors/{id} and POST .../enable, .../disable, .../test manage your MCP connectors: MCP servers you define (transport http, or stdio for administrators outside distributed mode), stored per user, with token, headers and env sealed and never returned; a test answers 200 with ok and the tool names or the error. Addresses on private networks are refused at connect time unless an administrator sets mcp_connectors_allow_private. A chat with no agent gets your enabled connectors; a saved agent names one as connector: in mcp_servers. GET /api/chats/{id}/tools lists the built-in tool groups, add-ons, model MCP servers and connectors of a chat with their switches. The built-in groups are on until PUT /api/chats/{id}/builtins {off: [...]} switches them off for that chat: shell (bash, whoever serves it; commands then says switched_off), web, files (the file tools and read_document), media (describe_image and transcribe_audio), collections, subagents (spawn_agent) and triggers; load_skill and the goal and loop tools have no switch, and a sub-agent follows its parent's switches; PUT /api/chats/{id}/mcp {off: [server name or connector:]} switches MCP servers and connectors off for that chat. GET /api/chats/{id}/mcp/prompts and .../mcp/resources list the prompts and resources of the servers the chat can use now; POST .../mcp/prompts {server, name, arguments} and POST .../mcp/resources/read {server, uri} return their text (403 mcp_refused for a server the chat cannot use); POST .../{id}/messages takes context: [{server, name, arguments} or {server, uri}] to add them to a message. MCP Apps: a tool that declares an interactive page (_meta.ui.resourceUri) gives its tool_end event and its transcript line an app {server, tool, resource_uri, visibility}; the transcript line also holds the call input and result. GET /api/chats/{id}/mcp-apps/resource?server=&uri= reads the ui:// page (html, mime_type, meta with csp, permissions and prefersBorder) for a server the chat may use now and a resource a tool of that server declares, and POST /api/chats/{id}/mcp-apps/call {server, tool, arguments} runs a tool of the same server whose visibility includes app, for the page to call; both answer 403 mcp_app_refused for anything else and need the MCP feature. Loops repeat a prompt inside a chat: POST .../{id}/loops {interval, prompt} starts one (interval such as 5m, at least chats_loop_min_interval; empty for a self-paced loop whose model calls schedule_next or loop_done after each run), GET .../{id}/loops lists them (also the loops field of GET /api/chats/{id}), PUT .../{id}/loops/{loopId} {state: paused|active} pauses, resumes or confirms one (the first loop of a chat is pending until confirmed), DELETE .../{id}/loops/{loopId} or DELETE .../{id}/loops stops them; a loops event tells other tabs, and a user line a loop sent carries loop {id, run}. A loop runs in its own chat and as often as every minute; a trigger starts a new chat at most once an hour."}, + {Name: "chats", Description: "Chats the server keeps: steering, sub-agents and live events", Tags: []string{"chats"}, Intro: "POST /api/chats starts a chat with a model; PATCH /api/chats/{id} {title, model, settings} renames it (1 to 80 characters), moves it to another model (history stays) or sets its settings {system_prompt, temperature, top_p, top_k, reasoning_effort, context_size}, which apply from the next turn (a new title or model needs an idle chat: 409 otherwise). POST .../{id}/regenerate answers the last message again, POST .../{id}/messages/{seq}/edit {text} replaces one of your messages and runs again from it (later lines are removed), POST .../{id}/fork {from_seq, title} copies a chat up to a line into a new chat, GET /api/chats/search?q= finds chats by title or text, GET .../{id}/export?format=markdown|json returns a chat as a file and POST /api/chats/import {chat, model} stores a JSON export as a new chat. Events also carry usage {used, limit, completion, tokens_per_second, model, node, prompt_ms} after each model request, for a context meter (node only when the server exposes the node header, prompt_ms only when the backend reports timings). Sub-agents: GET /api/chats/{id}/agents lists the sub-agent runs of a chat with running, last_turn and the background limit (from the shared store), GET .../{id}/agents/{agent_id}/messages reads one run's transcript and POST .../{id}/agents/{agent_id}/stop stops it; sub_agent_started and sub_agent_done events mark them in the parent's stream. A chat that PUT .../{id}/builtins {on: [\"saved_agents\"]} switched on (off by default; needs the agents feature and the chats_saved_agents setting) also gets list_agents and the agent argument of spawn_agent (a saved agent's id or name): the sub-agent then runs with that agent's instructions, model and grants. POST .../{id}/messages sends a message: with no turn running it starts one; with a turn running it waits (started false, pending_id) and reaches the model, together with any others and in order, at the model's next request. GET .../{id} lists the waiting messages; PATCH and DELETE .../{id}/pending/{pid} edit or cancel one until it is delivered (409 after). After a stop or a failed turn the waiting messages stay; POST .../{id}/send-now starts a turn from them and POST .../{id}/stop ends a running turn. Goals: PUT .../{id}/goal {text} sets a goal for the chat (it replaces the one it had, returned as replaced) and starts a turn on it when none runs; while the goal is active every turn's prompt carries it, the model gets goal_done {summary} and goal_blocked {reason}, and when a turn ends by itself the server starts the next one, until the goal is done or blocked, you stop it (POST .../{id}/stop pauses the goal), or chats_goal_max_turns (20 by default) automatic turns or chats_goal_max_steps (400) model steps pause it. Your messages still steer it: they go first. GET .../{id}/goal reads it {text, state active|paused|done|blocked, paused_by user|turn_limit|step_limit|error|interrupted, note, turns, max_turns, steps, max_steps}, DELETE .../{id}/goal clears it and POST .../{id}/goal/resume resumes a paused or blocked one with new counts; GET .../{id} carries it as goal, a goal event says it changed, and the transcript has goal lines (role goal, goal_event set|replaced|continue|paused|resumed|done|blocked|cleared). A chat that a trigger, a connector, a job or a page started, and a sub-agent run, cannot have a goal. A turn whose tool loop reaches the step limit (the runtime setting chats_max_iterations, 40 by default, or the model's agent.max_iterations) ends with last_turn paused after a paused event {steps}: the model answered from what it had, and a new message (for example \"Continue\") goes on. GET .../{id}/messages reads the transcript (a user line has text, the words typed, and attachments [{path, name, size, mime, version, missing}], the files it carried, with path inside your home for the files API; a waiting message has the same two fields; the model still gets the paths of the files with the message) and GET .../{id}/events streams live server-sent events, so read the transcript first. A chat is named after its first message. A conversation belongs to its user; another user's id is always 404. POST /api/chats/import/browser takes the chats the old chat page kept in the browser (the value of localStorage localai_chats_data) and stores them as yours; a chat that is there already is skipped. Needs the chats feature, which is on by default. Saved agents need the agents feature, triggers the triggers feature and connectors the connectors feature; all three are off by default for a user and an administrator grants them (an administrator has them all). The server can switch the chats off (LOCALAI_DISABLE_CHATS: every /api/chats path then answers 404 chats_off), and the triggers or the connectors alone (LOCALAI_DISABLE_TRIGGERS, LOCALAI_DISABLE_CONNECTORS: their routes answer 409 triggers_off or connectors_off); GET /api/features says what runs. Your files: GET /api/chats/files?path= lists a folder of your workspace (paths are inside your home, \"/\"), GET and PUT /api/chats/files/content?path= download and upload a file (a second upload that does not name the version it started from keeps both files and reports conflict_of), POST .../files/folders and .../files/move create and rename, DELETE .../files?path= moves to the Trash, GET .../files/trash lists deletions (each with files, folders and bytes, and totals for the whole Trash) and POST .../files/undo {rev} restores one, DELETE .../files/trash empties the Trash for good and DELETE .../files/trash/{rev} deletes one entry for good (neither can be undone; they touch only your own Trash and the agent tools never do this), GET .../files/history lists changes, GET .../files/search?q= searches names, text files and the text of PDF, Word, Excel and PowerPoint files (a document hit has document, page, sheet or slide; indexing counts documents still being read), and GET .../files/preview?path= reads a .xlsx, .xlsm, .csv, .tsv, .docx or .pptx file of up to 20 MiB for a preview (kind table: sheets of at most 200 rows by 30 columns with total_rows and total_cols; kind document: headings, list items, paragraphs and tables {type table, rows}; kind slides: titles, text and notes; 415 for another type). POST .../{id}/messages also takes multipart/form-data (text and files) to attach files (with a turn running the files are saved at once and the message waits with their paths): images go to a vision model inside the message (image_url parts; other models get the path and describe_image), videos to a model that takes video, and the text of PDF, Word, Excel, PowerPoint and EPUB files is added to the message (the model reads the rest with read_document). Skills: GET /api/chats/skills?chat= lists the skills of the five layers (folder, personal, shared, addon, builtin; an addon skill names its add-on in addon and addon_title) with enabled and shadowed, POST creates one {layer personal|shared, name, description, body} (shared needs an administrator), GET PUT DELETE .../skills/{layer}/{name} read, change and delete (to the Trash), PUT /api/chats/{id}/skills {off} switches skills off for one chat. Well-known files: GET and PUT /api/chats/wellknown/{name} (persona, user, shortcuts, home, ui, or widget-data with ?path=) read and change the files of your home that set the assistant's persona, your profile, the composer shortcuts, the Home widgets and the look. A read is validated against the JSON Schema at .../wellknown/{name}/schema and falls back to the last valid version (fallback, errors); a write {values, replace} merges the keys it sends (null removes one), takes the version you read in If-Match (409 with current when the file changed) and is refused with errors when the result is invalid; POST .../wellknown/{name}/revert restores the previous valid version as a new change, or the version {rev} that GET .../wellknown/{name}/versions lists (newest first, with who wrote it and in which chat). A checkpoint line of a transcript carries rev, the change set of the turn, and lists the paths it changed. Add-ons: GET /api/chats/{id}/addons lists the add-ons whose tools you may use, each with its switch for that chat, and PUT /api/chats/{id}/addons {off: [ids]} switches the tools of add-ons off for one chat. Commands: a chat runs commands with bash, served by an add-on that runs commands (isolated) or, when no add-on serves it, by the built-in bash directly on this machine with no isolation and with its network; the add-on list says which (commands_provider, commands_isolation, commands_consent, commands_fallback). With chats_host_exec ask, each command waits: a host_exec_consent event carries {ids: [id], text: command} and POST /api/chats/{id}/host-exec/consent {id, decision: once|deny} answers it (once needs an administrator). Administrators: GET /api/chats/admin/tools lists the built-in tools an add-on may replace (Settings > Tools; change them with POST /api/settings chats_host_exec and chats_tool_providers) and GET /api/chats/admin/host-exec/events?limit= reads the audit of the commands run on this machine. Network of the isolated commands: the guest has no network device and reaches HTTP and HTTPS only through a proxy that asks the server about each connection. GET /api/chats/{id}/egress returns {preset, ceiling, effective, applies, applies_reason, addon, registries, rules, cards} (applies is false when commands run on this machine, which has the server's network; addon is the add-on that runs the commands and draws the chat's network controls), PUT .../{id}/egress {preset: off|registries|all} sets the chat's preset (400 egress_above_ceiling above the administrator's chats_egress_ceiling), DELETE .../{id}/egress/rules/{host}/{port} removes an allow or deny rule, an egress_consent event {ids: [card id], text: host:port} asks for a host the chat does not allow (the command waits up to 60 seconds) and POST .../{id}/egress/consent {id, decision: once|chat|deny} answers it (allowing a host inside your network needs an administrator), and egress_card events say that the chat's network changed. Administrators: GET /api/chats/admin/egress reads the chats_egress_* settings in force, the registries and the counts of the last 24 hours, and GET /api/chats/admin/egress/events?limit=&user=&chat=&verdict=&host= reads the audit. Saved agents: GET and POST /api/chats/agents, GET PUT DELETE .../agents/{id}: an agent is {name, description, instructions, model, mcp_servers, addons, collections, skills, network, folder}; folder {path, mode read|write} gives it one folder of your files (\"/\" is all of them; not LocalAI, Chats or a shared folder; 400 otherwise), kept by the folder itself so a rename or move is followed, shown back as {path, name, mode, state ok|missing|unset}; a write without folder keeps it and folder {path: \"\"} clears it; network (off, registries or all; off by default) is the network of the isolated commands of its trigger and connector runs, capped by chats_egress_ceiling, which never show a card; the lists are exact grants (an empty list grants nothing) and a chat gets only what you may use at that moment. POST /api/chats {agent_id} starts a chat with one (the agent's model replaces model when it has one). GET .../agents/{id}/export returns the definition as a JSON file (version 1, kind localai-agent; version 2 with folder {path, mode} for an agent with a folder, which a server that knows only version 1 refuses), POST .../agents/import takes that file (JSON body or multipart file field) and saves a new agent (a taken name gets a number, an unavailable model is dropped, a folder you do not have leaves the agent unset until you choose one; warnings say so), GET .../agents/templates lists starter agents and POST .../agents/templates/{id}/create saves one, GET .../agents/{id}/runs lists the chats that ran with the agent (yours, trigger runs, connector runs) with last_turn and counts. Inbox: GET /api/chats/notifications?unread=1 lists the notifications of your trigger runs (kind run_ended, run_failed or needs_attention) with the unread count, GET .../notifications/count counts them, POST .../notifications/read {ids} or {all: true} marks them read, DELETE .../notifications {ids} removes some, or {all: true} empties your inbox ({all: true, read_only: true} removes only the read ones; the answer has deleted and the unread count left), the list also gives total (everything kept, since limit, at most 500, can cut the list), and GET .../notifications/events streams new ones as server-sent events plus a notifications_changed event when notifications were read or deleted (from any tab or frontend), after which a client reads the list again. A user only ever reaches their own notifications. Opening a chat (GET /api/chats/{id}) marks its notifications read. Triggers: GET and POST /api/chats/triggers, GET PUT DELETE .../triggers/{id}, POST .../{id}/run (start now), .../{id}/enable and .../{id}/disable, GET .../{id}/runs, GET .../triggers/preview?when=&tz= (next times of a schedule). A trigger is {name, prompt, kind schedule|file, schedule + time_zone, or folder + quiet_seconds, daily_cap, enabled, agent_id, model, source_chat_id}: it starts a chat as you by itself, on a schedule (\"daily 08:00\", \"weekdays 09:30\", \"weekly mon,thu 09:30\", \"monthly 15 08:00\", \"once 2026-12-24 18:00\" or five cron fields) or when a file arrives in the folder; a chat it starts has origin trigger. A trigger also has plan {reads, writes, widget} (what a run reads, the file it rewrites and the Home widget that shows it), cost {estimated_tokens, average_tokens, runs, max_runs_per_day, remote} and last_done, and each run its tokens; a file trigger waits min_gap_seconds (60 by default) after a run before a file that changed again starts another. The four trigger tools (propose_trigger, list_triggers, update_trigger, delete_trigger) are the built-in tool group triggers: on in a chat a person starts, switched together with PUT .../{id}/builtins {off: [\"triggers\"]}, listed in GET .../{id}/tools and GET .../draft/tools with usable and reason (not usable in a run a trigger or connector started, for a user without the triggers feature; not listed when the server runs no triggers), and never given to a sub-agent. A model can propose a trigger in a chat (propose_trigger; a schedule from a chat runs at most once an hour); GET .../triggers/proposals?chat= lists them, PUT .../triggers/proposals/{id} edits one (it stays a proposal), POST .../triggers/proposals/{id}/confirm {time_zone} turns one into a trigger that is on, DELETE dismisses it (the answer is kept: GET .../triggers/proposals/{id} returns {state pending|accepted|declined|undone, trigger, answered_at, can_undo, undo_blocked}, POST .../undo takes an accepted one back unless the trigger ran or was edited since (409 says why) and POST .../reopen restores a declined or undone one); the chat carries a proposal as a card {kind trigger_proposal, id} on the tool line (tool_end event and transcript) and as a trigger_proposed event. A model can also ask to change a trigger of yours (list_triggers gives each a ref; update_trigger edits, pauses or resumes, delete_trigger deletes): an edit or a delete waits for you, and a pause or a resume applies at once; the chat carries it as a card {kind trigger_change, id}. GET .../triggers/changes/{id} returns {id, op update|delete|pause|resume, state pending|applied|dismissed|undone, trigger_id, before, after, fields, answered_at, stale, can_undo, undo_blocked, last_run}, POST .../changes/{id}/apply makes it (409 when the trigger changed since), DELETE dismisses it and POST .../changes/{id}/undo puts the trigger back as it was, for a day after it applied (a deleted trigger comes back with its id, without its run history). Proposed changes: a model asks to change your memory or an agent profile with propose_change {kind memory|profile, scope user|agent|channel, target, content, summary} (in the built-in tool group changes; revert_change {id} undoes an applied one). Nothing is written until you confirm. GET /api/chats/changes?status= lists the proposals (id, kind, scope, target, summary, content, source {kind, id, chat}, status pending|applied|dismissed|expired|reverted|stale, rev), GET .../changes/{id} reads one, POST .../changes/{id}/confirm writes it as one change set, or with a body {content} your own text in its place (409 when the file changed since, the proposal expired after 24 hours or it was answered), POST .../changes/{id}/dismiss answers no, POST .../changes/{id}/undo restores the file (409 when it was edited since) and GET .../changes/audit lists who proposed, confirmed or reverted what, with a hash and never the text. GET /api/chats/context-files lists the notes the host puts in the prompt (limits, and groups of {source, scope, key, max_bytes, max_lines, files}) for the Memory tab of Your settings; it only reads. At most 10 proposals wait per user and 5 are made per hour per agent. A chat that runs a saved agent cannot propose until the agent is granted it. Browser push: GET /api/chats/push/key returns the server's VAPID public key, POST /api/chats/push/subscribe takes a browser PushSubscription {endpoint, keys: {p256dh, auth}} (an https endpoint on a public address) and DELETE .../push/subscribe {endpoint} removes it; a notification is then pushed with its title and link only. These answer 409 push_off when the server keeps nothing across a restart. Conversion: at start the server converts the old chat page, agents, tasks, skills and Telegram connectors; GET /api/chats/conversion lists what happened to your items (kind, name, status converted|skipped|failed|dropped, reason) and gives an administrator the totals. Converted triggers and connectors are switched off. Connectors: GET /api/chats/connectors/kinds lists the platforms that an installed add-on serves (each kind comes with the add-on that serves it), GET and POST /api/chats/connectors, GET PUT DELETE .../connectors/{id}, POST .../{id}/enable, .../disable and .../test (asks Telegram who the bot is), GET .../{id}/senders (who wrote to the bot) and POST .../{id}/senders/{sender}/allow. A binding is {kind (the platform, telegram when empty; set at create only), name, token (write-only, sealed, never returned; has_token says it is stored), agent_id (required: an agent of yours that names a model), enabled, accept_any, allow [chat IDs, user IDs or @usernames], notify_chat}: a person who messages the bot talks to that agent in a conversation of their own, as you, with only the agent's grants. The allowlist is empty at first, so nobody is accepted; a sender who is not accepted is ignored and logged. accept_any lets anyone who can message the bot use the agent; the create or update that turns it on must also send confirm_accept_any: \"accept any message\" (else 400). Files and skills answer 409 with the reason when the server has no data path. Administrators: GET /api/chats/admin/agents, .../admin/triggers and .../admin/connectors list what every user has, each with its owner and never a token or instructions; GET .../admin/triggers/{id}/runs lists the runs of a trigger, POST .../admin/triggers/{id}/disable and .../admin/connectors/{id}/disable switch one off, and DELETE .../admin/agents/{id}, .../admin/triggers/{id} and .../admin/connectors/{id} remove one. No MCP tool maps to these routes: they are the user's own chat and files, not administration. GET POST /api/chats/mcp-connectors, GET PUT DELETE /api/chats/mcp-connectors/{id} and POST .../enable, .../disable, .../test manage your MCP connectors: MCP servers you define (transport http, or stdio for administrators outside distributed mode), stored per user, with token, headers and env sealed and never returned; a test answers 200 with ok and the tool names or the error. Addresses on private networks are refused at connect time unless an administrator sets mcp_connectors_allow_private. A chat with no agent gets your enabled connectors; a saved agent names one as connector: in mcp_servers. GET /api/chats/{id}/tools lists the built-in tool groups, add-ons, model MCP servers and connectors of a chat with their switches. The built-in groups are on until PUT /api/chats/{id}/builtins {off: [...]} switches them off for that chat: shell (bash, whoever serves it; commands then says switched_off), web, files (the file tools and read_document), media (describe_image and transcribe_audio), collections, subagents (spawn_agent) and triggers; load_skill and the goal and loop tools have no switch, and a sub-agent follows its parent's switches; PUT /api/chats/{id}/mcp {off: [server name or connector:]} switches MCP servers and connectors off for that chat. GET /api/chats/{id}/mcp/prompts and .../mcp/resources list the prompts and resources of the servers the chat can use now; POST .../mcp/prompts {server, name, arguments} and POST .../mcp/resources/read {server, uri} return their text (403 mcp_refused for a server the chat cannot use); POST .../{id}/messages takes context: [{server, name, arguments} or {server, uri}] to add them to a message. MCP Apps: a tool that declares an interactive page (_meta.ui.resourceUri) gives its tool_end event and its transcript line an app {server, tool, resource_uri, visibility}; the transcript line also holds the call input and result. GET /api/chats/{id}/mcp-apps/resource?server=&uri= reads the ui:// page (html, mime_type, meta with csp, permissions and prefersBorder) for a server the chat may use now and a resource a tool of that server declares, and POST /api/chats/{id}/mcp-apps/call {server, tool, arguments} runs a tool of the same server whose visibility includes app, for the page to call; both answer 403 mcp_app_refused for anything else and need the MCP feature. Loops repeat a prompt inside a chat: POST .../{id}/loops {interval, prompt} starts one (interval such as 5m, at least chats_loop_min_interval; empty for a self-paced loop whose model calls schedule_next or loop_done after each run), GET .../{id}/loops lists them (also the loops field of GET /api/chats/{id}), PUT .../{id}/loops/{loopId} {state: paused|active} pauses, resumes or confirms one (the first loop of a chat is pending until confirmed), DELETE .../{id}/loops/{loopId} or DELETE .../{id}/loops stops them; a loops event tells other tabs, and a user line a loop sent carries loop {id, run}. A loop runs in its own chat and as often as every minute; a trigger starts a new chat at most once an hour."}, {Name: "pages", Description: "Pages: HTML pages in your workspace that the UI shows in a sandboxed frame", Tags: []string{"pages"}, Intro: "A page is the folder pages// of your home (name ^[a-z0-9][a-z0-9-]{0,63}$) with an index.html, an optional page.json {title, icon, description, widget: {size small|medium|large, title}} and its data files; a page with a widget block can be a tile on Home (a widget {type: page, page: , folder?: } in LocalAI/home.json, at most 3), where it runs with localai.page.mode \"widget\". GET /api/chats/pages lists them (source own, author you or assistant, updated_at, updated_by); GET /api/chats/pages/{name} returns the page with its HTML (at most 1 MiB). The bridge of a page: GET /api/chats/pages/{name}/files?dir=, GET and PUT /api/chats/pages/{name}/file (text files of at most 1 MiB, paths relative to the page's folder; a page writes data files only, code and document files such as .js, .css, .html, index and page.json are refused with 403; writes are rate limited; GET .../file?path=&encoding=base64 reads an image of the folder as base64, which the UI puts into the page), and POST /api/chats/pages/{name}/chat {text, chat_id, model} to put a message in a chat after the person confirmed it. GET /api/chats/page-starters and POST /api/chats/page-starters/{id}/copy copy a starter page. Write a page with the files API or from a chat. Shared pages: GET /api/chats/shared-pages lists the pages of the folders an administrator shared with you (folder, folder_id, author_name, hash, code_files, consent none, allowed or changed; the hash covers index.html, page.json and code_files, the scripts, style sheets and modules the page names, so a change to any of them asks again; enabled false when an administrator turned shared pages off). GET /api/chats/shared-pages/{folder_id}/{name} returns one with its HTML and your consent; PUT .../consent {hash, once} allows that version (once gives a visit token), DELETE .../consent revokes it. The bridge of a shared page is .../files, .../file and .../chat as for your own pages, each with the header X-LocalAI-Page-Hash (the version that runs) and X-LocalAI-Page-Visit for a visit allowed once; without a consent it answers 403 page_not_allowed, a read of a file of code by a frame of an older version answers 409, and a read-only grant cannot write. Needs the chats and pages features (pages is off by default for users who are not administrators)."}, {Name: "addons", Description: "Owner-routed addon lifecycle and response relays", Tags: []string{"Addons"}, Intro: "POST /api/addons/dispatch submits typed lifecycle operations or reads actor-bound operation-status. POST /api/addons/relay serves status and coarse lifecycle progress on the receiving frontend. Named authentication and the addons feature are required; lifecycle operations require administration. Preserve operationId after outcome_unknown and poll status, never submit a new mutation. An add-on that refuses a request as invalid answers 400 invalid_request from every route, never an outage: nothing was applied, so correct the request instead of repeating it. Resource and output routes deny access until host admission and resolution providers are installed. Data and schema mutations are stored proposals: POST /api/addons/proposals previews and stores one (nothing is applied), GET /api/addons/proposals/{id} reads it, GET /api/addons/proposals?state=pending lists the caller's own pending proposals (newest first, at most 32; where a proposal made through the OpenAI-compatible chat route, an API client or an MCP session waits for the proposer's own browser session; the chats of /api/chats, their agents and their triggers apply a change at once because turning the add-on on for the chat is the consent, and are not proposals), POST .../cancel withdraws one and POST .../reconcile resolves an unknown outcome by receipt lookup, and when no receipt can be found POST .../resolve lets the resource owner's own browser session abandon it with a reason (same confirmation-surface rules as confirm; nothing is applied again). The owner role finds what to resolve with GET /api/addons/resources/{resourceId}/proposals?state=unresolved (same rules, X-LocalAI-Confirm equals the resource ID): it lists the proposal ID, proposer, effects, digest and age of every unresolved proposal on the resource, never its arguments. A write blocked by an unresolved outcome is denied (403) and, for the owner role only, names it as outcome_blocked with blockedBy. POST .../confirm applies exactly the stored operation once and is accepted only from the proposer's own browser session (same-origin fetch, X-LocalAI-Confirm header equal to the proposal ID, digest of what was shown); API keys, MCP sessions and tool or agent calls can propose but never confirm, and no MCP tool maps to confirm. Sharing and database deletion are never proposals. A read that returns a file result gives private artifact IDs, never addon handles: GET /api/addons/artifacts/{id} returns the transfer state, name, size and expiry, and GET /api/addons/artifacts/{id}/download streams the complete file as an attachment. Only the requesting principal can read or download an artifact, an unknown, foreign or expired ID is the same 403, access to every source resource is checked again at completion and while streaming, and a disabled addon denies downloads until it is enabled again. Only GET /backends/library/updates has an MCP tool, list_backend_library_updates; no MCP tool maps to the other routes. The Apps surface: GET /api/addons/apps lists the installed, enabled addons any caller with the addons feature may use, with title, description, icon URL, version, generation, state (running, starting, failed or stopped; an observation separate from enabled), a main page path only when the manifest declares a valid one, and a bounded tool summary; administrators also see disabled addons and per-app controls. GET /api/addons/apps/{id}/icon?generation=N serves the verified icon of a visible app. POST /api/addons/apps/{id}/start and .../stop are administrator-only, take {operationId, generation} with the generation that was listed, deny a stale generation and keep the lifecycle rules (preserve operationId after outcome_unknown). No MCP tool maps to the Apps routes. The listed ui entry of an app gives the same-origin URLs of its UI code: GET /api/addons/{id}/assets/{digest}/{path} streams one declared file (the entry module or a style sheet) of the current installed package, relayed from the owner, with Cache-Control private, max-age=31536000, immutable and nosniff. The digest is the package sha256 in lower-case hex; a file the manifest does not declare, a traversal, another addon, an older package and a disabled or uninstalled addon are all one 403, never cached. A credential in the URL is never accepted; the browser uses its same-origin session. No MCP tool maps to the asset route. Management (administrators only, through POST /api/addons/dispatch): the reads catalog-search, catalog-details, catalog-sources and addons-installed return catalog entries, one resolved entry, the configured libraries with their last fetch state and the installed addons with verified package facts, health, retained generations and storage; catalog-source-save stores or removes a library by reference only (a secret in place of a reference is denied) and catalog-source-refresh fetches one again; upgrade installs a newer release of an installed addon. Removing a library never touches installed addons. The installed view has an update object computed by the owner's update check (state, candidate version and digest, check and last-success time, reasons, redacted error class); an add-on the owner cannot answer for has none, and a failed check is never up-to-date. No MCP tool maps to these actions. UI-only resource management (never tools; no MCP tool maps to any of it): GET /api/addons/resources?addonId=tables lists the resources the caller owns or that were shared with the caller, with the caller's own role, the display name, the owner's display name for a shared one and, for the owner role only, the number of people it is shared with and the revision. POST /api/addons/resources creates one by the person's own action (operationId makes it idempotent; the arguments are the add-on's create tool arguments), POST .../{resourceId}/rename and .../delete rename and delete it (the owner role only; generation and revision must be the listed ones or the call is 409 stale; delete needs confirm equal to the display name, removes the data and every grant and never uninstalls the add-on), GET .../{resourceId}/grants, PUT/DELETE .../grants/{userId} and GET .../{resourceId}/users?q= list, set (viewer or editor, whole resource) and remove grants and search the people it can be shared with (immutable account ID and display name only; local-owner mode answers 409 sharing_disabled). All of them accept only the owner's own browser session with the X-LocalAI-Confirm header equal to the resource ID (the operation ID for a creation); API keys are refused. POST .../{resourceId}/apply changes the data or the schema by the person's own action with no card, through a write or schema tool the add-on declares ({operationId, generation, revision, tool, arguments} with the revision the caller read; editors write rows, only the owner changes the schema; 409 stale when the generation or revision moved; the same operationId with the same request is one change; reads, creations, rename, delete and undeclared tools are refused). POST .../resources/{resourceId}/changes/{changeId}/undo ({operationId, generation}) undoes one change an add-on tool made at once from a chat, an agent or a trigger, by the change set the add-on kept for it; the change ID is the one the tool result named (undoable true, changeId, undo). It is the person's own action in a browser tab and accepts only the browser session with X-LocalAI-Confirm equal to the resource ID: an API key, an MCP session or a tool call is refused, so a model can never undo work. The role is the one the change needed (editors undo data changes, only the owner role undoes a schema change or a creation). It is applied against the revision the add-on just reported: when the resource changed after the change the answer is 409 stale with the words of what changed and nothing is overwritten. The other refusals are typed: not_found (404), expired (410, after 7 days), already_undone (409) and cannot_undo (409, for example a job that finished); the same operationId with the same change is one undo. GET .../resources/{resourceId}/operations/{operationId}?kind=rename|delete|apply|undo reads the receipt of a rename, a deletion, a change or an undo after outcome_unknown, which carries the original operationId. GET/PUT/DELETE /api/addons/conversations/{conversationId}/selection/{addonId} keep the resource a conversation works on for the authenticated user; a chat tool call that names no resourceId uses it, authorized again by the owner on every call, and with none selected the tool answers an error result with code select_resource. Data recovery (administrators only, never tools; no MCP tool maps to any of it): GET /api/addons/{id}/recovery returns the recovery state of an add-on's data (ready, upgrading, restoring, needs-recovery or purging), its backups newest first with size, reason, mode and last verification result, the retention policy and the receipt of the last restore. POST /api/addons/{id}/recovery/backup makes a verified, consistent backup (the add-on is stopped while its SQLite files are copied with VACUUM INTO, admission is blocked and pending proposals are invalidated; nothing is left behind on failure; 503 insufficient_storage when it does not fit), .../verify reads one completely, .../restore restores one (the add-on must not be running, confirm is the add-on ID, mapping names the account that takes the data of a backup made in local-owner mode, the answer carries warnings and no share is given back that was removed since the backup or whose account is gone; 409 needs_recovery, addon_running, backup_corrupt, incompatible_format, identity_changed, mapping_required or downgrade_unsupported), .../delete-backup removes one (never the only verified copy, 409 sole_recovery_copy) and .../prune applies the retention policy. POST /api/addons/{id}/purge removes retained data by explicit scope (data, backups, recoveryCopies) with confirm equal to the add-on ID, for an add-on that is uninstalled or disabled; it is not a database deletion or an uninstall. Every mutation accepts only the administrator's own browser session (same-origin fetch, X-LocalAI-Confirm equal to the operationId); a repeated operationId returns the recorded result and never runs again; after outcome_unknown read the state and keep the operationId. An upgrade of an add-on that has data is backed up, migrated under exclusive ownership and published only when healthy; a failed migration that changes the data format leaves the add-on in needs-recovery with the previous package and the verified backup retained. Updates (never tools; no MCP tool maps to any of it): GET /api/addons/{id}/update reads the owner's update status of an installed add-on for every caller with the addons feature who may see it (administrators any installed add-on, others an enabled one; the same 403 otherwise). The state is unknown, up-to-date, update-available, incompatible (reasons: platform, host-version, api-version, protocol-version, sdk-version, data-format), check-failed (a redacted error class and lastSuccess, the time the library was last read; never shown as up-to-date) or integrity-error (an immutable version was listed again with another digest; never an update). A moving channel (development, a branch, latest) compares resolved digests, so a changed digest with the same version label is an update; an immutable version selects the highest compatible greater version of the same major. The library and the channel the add-on came from never change by themselves. Callers who are not administrators get the state, versions and times only. The route never uses the network. POST /api/addons/{id}/update/check (administrators, own browser session, X-LocalAI-Confirm equal to the operationId) fetches the library again and returns the status; it is rate limited and answers throttled true when it did not fetch, and it applies nothing. POST /api/addons/{id}/upgrade (administrators, own browser session) is the only request that applies an update: it carries operationId, expectedDigest (the installed package the caller saw) and candidateDigest (the candidate the check resolved), and the owner re-resolves, re-checks compatibility and refuses before it records anything with 409 stale_installed, candidate_changed, incompatible, integrity_error or upgrade_conflict (the same transition under another operationId); 503 check_failed when the library cannot be read. A failure keeps the last good generation or enters the recovery state; the previous installation is never deleted. The apps list marks an app update: update-pending from the owner's cached check only and never reaches a library."}, {Name: "library-sources", Description: "Library sources of add-ons, backends and models", Tags: []string{"library"}, Intro: "Administrators only. GET /api/library/sources lists every source of the add-on, backend and model kinds, shipped defaults and removed defaults (tombstones) included, with kind, id, name, url, mirrors, enabled, default, removed, suspended, a conflict message and the last fetch state. POST /api/library/sources adds a source of your own ({kind: addon|backend|model, url, id, name, format: library|gallery}); the same kind and URL twice is a 409. POST /api/library/sources/{id}/enable and /disable turn one on or off (enabling a removed default brings it back). PUT /api/library/sources/{id} replaces the mirrors of a model or backend source ({mirrors: [..]}); POST also takes mirrors. Each mirror is an http(s), github:, oci:// or file:// address, at most 8. DELETE /api/library/sources/{id} removes a source; a shipped default stays as a tombstone so it does not return at the next start. The routes work on the store that `local-ai library` edits. On a frontend (--addons-role=frontend) the routes forward to the add-on owner, which is the only writer; they answer 503 when the owner is not reachable or runs on another platform. `GET /backends/library/updates` and `POST /backends/library/install` forward the same way. The runtime setting official_libraries (default on) turns every shipped default off at once: they stay listed with suspended true. No MCP tool maps to these routes."}, diff --git a/core/http/endpoints/studio/studio.go b/core/http/endpoints/studio/studio.go index f433cc5494..33f1474003 100644 --- a/core/http/endpoints/studio/studio.go +++ b/core/http/endpoints/studio/studio.go @@ -144,7 +144,7 @@ var chatRules = []errRule{ fixed(http.StatusNotFound, typeNotFound, "no such network card", studiosvc.ErrEgressNoCard), fixed(http.StatusBadRequest, typeInvalid, "the answer must be once, chat or deny", studiosvc.ErrEgressBadDecision), fixed(http.StatusConflict, "already_answered", "the network card was answered already with another answer", studiosvc.ErrEgressAnswered), - fixed(http.StatusBadRequest, "egress_above_ceiling", "the limit an administrator set for the Sandbox network does not admit this host; an administrator can raise it on the Settings tab of the add-on that runs the commands", studiosvc.ErrEgressHostAboveCeiling), + fixed(http.StatusBadRequest, "egress_above_ceiling", "the limit an administrator set for the network of commands does not admit this host; an administrator can raise it on the Settings tab of the add-on that runs the commands", studiosvc.ErrEgressHostAboveCeiling), fixed(http.StatusForbidden, typeAuthz, "only an administrator can allow a host inside your network; anyone can deny it", studiosvc.ErrEgressDecision), verbatim(http.StatusConflict, typeConflict, "", studiosvc.ErrGoalNotAllowed, studiosvc.ErrGoalReached), verbatim(http.StatusNotFound, typeNotFound, "", studiosvc.ErrNoGoal), diff --git a/core/services/studio/capabilities.go b/core/services/studio/capabilities.go index c32c85f6f3..e5b4d4839c 100644 --- a/core/services/studio/capabilities.go +++ b/core/services/studio/capabilities.go @@ -321,6 +321,16 @@ func commandsTitle(c Commands) string { return "the add-on" } +// commandsPhrase names the add-on that runs commands in a sentence: the +// declared title when there is one, else a generic description. The title comes +// from the add-on's declaration, never from this file. +func commandsPhrase(c Commands) string { + if c.Title != "" { + return "the " + c.Title + " add-on" + } + return "the add-on that runs commands" +} + // commandsBlock is the block of the system prompt that states whether the chat // can run commands. writeFile says whether the chat has write_file, // fileTools whether it has the file tools to read them, and skillsOff @@ -365,9 +375,9 @@ func commandsBlock(c Commands, writeFile, fileTools, skillsOff bool, place sessi case CommandsSwitchedOff: b.WriteString("they switched running commands off for this chat and can switch Run commands on in its Tools menu.") case CommandsOff: - b.WriteString("they can switch the " + commandsTitle(c) + " add-on on in the Tools menu of this chat.") + b.WriteString("they can switch " + commandsPhrase(c) + " on in the Tools menu of this chat.") case CommandsUnavailable: - b.WriteString("the " + commandsTitle(c) + " add-on cannot run commands on this server; an administrator can fix that.") + b.WriteString(commandsPhrase(c) + " cannot run commands on this server; an administrator can fix that.") default: b.WriteString("an administrator can enable running code by installing an add-on that runs commands.") } diff --git a/core/services/studio/commandaccess_test.go b/core/services/studio/commandaccess_test.go index c8bd00bcfb..fc743037ff 100644 --- a/core/services/studio/commandaccess_test.go +++ b/core/services/studio/commandaccess_test.go @@ -123,7 +123,7 @@ var _ = Describe("commands of a scoped chat", func() { g := shellGroup(r.svc, alice, rec.ID) Expect(g.Usable).To(BeFalse()) Expect(g.Reason).To(ContainSubstring("works in one folder")) - Expect(g.Reason).To(ContainSubstring("Sandbox")) + Expect(g.Reason).To(ContainSubstring("only in an add-on that isolates them")) cmds, err := r.svc.CommandRunner(r.ctx, alice, rec.ID) Expect(err).NotTo(HaveOccurred()) Expect(cmds.State).NotTo(Equal(studio.CommandsAvailable)) diff --git a/core/services/studio/egress/egress.go b/core/services/studio/egress/egress.go index 93317b98d3..293e0f539e 100644 --- a/core/services/studio/egress/egress.go +++ b/core/services/studio/egress/egress.go @@ -504,7 +504,7 @@ func Describe(p Preset, reg *Registries, asks bool) string { case PresetRegistries: return "Network for commands: package registries only (" + strings.Join(reg.Titles(), ", ") + ")." + tail case PresetAll: - return "Network for commands: all public sites, through the proxy the sandbox sets." + tail + return "Network for commands: all public sites, through the proxy of the environment that runs them." + tail } return "Network for commands: off." + tail } @@ -517,10 +517,10 @@ func Describe(p Preset, reg *Registries, asks bool) string { func DescribeLimit(eff, ceiling Preset, reg *Registries, asks bool) string { const where = "An administrator can change it on the Settings tab of the add-on that runs the commands, on the Add-ons page." if normal(ceiling) == PresetOff { - return "Network for commands: off. The server's setting for the Sandbox network does not allow any access, and no user approval changes that, so do not wait for one or retry a blocked request. " + + return "Network for commands: off. The server's setting for the network of commands does not allow any access, and no user approval changes that, so do not wait for one or retry a blocked request. " + "Tell the user the network is off by the server's setting. " + where } - return Describe(eff, reg, asks) + " The server's setting for the Sandbox network limits it; a host outside the limit is blocked by that setting, not by a missing approval, so do not retry it. Tell the user. " + where + return Describe(eff, reg, asks) + " The server's setting for the network of commands limits it; a host outside the limit is blocked by that setting, not by a missing approval, so do not retry it. Tell the user. " + where } // Hint is the sentence after Describe in the turn's note: which tool to use @@ -533,7 +533,7 @@ func Hint(p Preset, web bool) string { return "curl, pip and git cannot reach anything now; ask the user to turn the network on if a task needs it." } if web { - return "curl, pip and git work in the sandbox through the proxy. To read or search web pages use web_fetch or web_search; use curl for APIs, downloads and installs." + return "curl, pip and git work in the isolated environment through the proxy. To read or search web pages use web_fetch or web_search; use curl for APIs, downloads and installs." } - return "curl, pip and git work in the sandbox through the proxy." + return "curl, pip and git work in the isolated environment through the proxy." } diff --git a/core/services/studio/egress/egress_test.go b/core/services/studio/egress/egress_test.go index 5af5544ad4..5321ae5c86 100644 --- a/core/services/studio/egress/egress_test.go +++ b/core/services/studio/egress/egress_test.go @@ -283,7 +283,7 @@ var _ = Describe("the registries list", func() { h := egress.Hint(egress.PresetOff, web) Expect(h).To(ContainSubstring("cannot reach anything")) Expect(h).NotTo(ContainSubstring("web_")) - Expect(h).NotTo(ContainSubstring("work in the sandbox")) + Expect(h).NotTo(ContainSubstring("work in the isolated environment")) } }) }) diff --git a/core/services/studio/egresscards.go b/core/services/studio/egresscards.go index dc60f6d0cd..b970dd7dab 100644 --- a/core/services/studio/egresscards.go +++ b/core/services/studio/egresscards.go @@ -46,7 +46,7 @@ var ( // ErrEgressHostAboveCeiling means the administrator's limit does not admit // the host of the card, so only an administrator can make it work, by // raising the limit. The card is refused and stays so. - ErrEgressHostAboveCeiling = errors.New("studio: the limit an administrator set for the Sandbox network does not admit this host") + ErrEgressHostAboveCeiling = errors.New("studio: the limit an administrator set for the network of commands does not admit this host") ) // EgressDecision is the answer of a card, sent on the chat bus to the check diff --git a/core/services/studio/egresscheck.go b/core/services/studio/egresscheck.go index 0409b7effe..3f0d3a4fe8 100644 --- a/core/services/studio/egresscheck.go +++ b/core/services/studio/egresscheck.go @@ -224,7 +224,7 @@ func (s *Service) EgressAudit(ctx context.Context, user, rid string, evs []Egres func (s *Service) auditEgress(ctx context.Context, e audit.Event) { if err := s.egressAudit().Add(context.WithoutCancel(ctx), e); err != nil { - s.log.Warn("Chats: could not audit a Sandbox network request", "error", err) + s.log.Warn("Chats: could not audit a command network request", "error", err) } } diff --git a/core/services/studio/hostbash.go b/core/services/studio/hostbash.go index b79e90ddea..83812c961c 100644 --- a/core/services/studio/hostbash.go +++ b/core/services/studio/hostbash.go @@ -101,11 +101,10 @@ func (s *Service) isAdmin(ctx context.Context, user string) bool { func (s *Service) registerHostBash() error { host := s.d.HostExec != nil return s.builtins.Register(builtins.Tool{ - ID: commandTool, - Group: builtins.GroupShell, - Label: "Commands (bash)", - Description: "Runs commands and code for the chats directly on this machine, with no isolation: commands can read what LocalAI can read " + - "and reach the internet and your network. The Sandbox add-on replaces it with isolated commands.", + ID: commandTool, + Group: builtins.GroupShell, + Label: "Commands (bash)", + Description: hostBashDescription, Setting: builtins.SettingHostExec, Unlisted: !host, Replaceable: true, @@ -115,10 +114,15 @@ func (s *Service) registerHostBash() error { }) } +// hostBashDescription is the line of Settings > Tools for the built-in bash. +// It says that an add-on can replace it and names none. +const hostBashDescription = "Runs commands and code for the chats directly on this machine, with no isolation: commands can read what LocalAI can read " + + "and reach the internet and your network. An add-on that runs commands in isolation can replace it." + // scopedHostBashReason is why a chat whose agent works in one folder has no // built-in bash (D10 of the agent folder design): a command on this machine // reads what the server can read, and no workspace rule confines it. -const scopedHostBashReason = "this agent works in one folder, and commands on this machine could read files outside it; it runs commands only in the Sandbox add-on" +const scopedHostBashReason = "this agent works in one folder, and commands on this machine could read files outside it; it runs commands only in an add-on that isolates them" // buildHostBash gives a chat the built-in bash when the setting allows it. // A chat whose actor is fenced (its agent, or its parent's, has a folder) diff --git a/core/services/studio/hostexec/hostexec.go b/core/services/studio/hostexec/hostexec.go index 7f67eb0b80..f9322c7464 100644 --- a/core/services/studio/hostexec/hostexec.go +++ b/core/services/studio/hostexec/hostexec.go @@ -177,7 +177,7 @@ var ErrScoped = errors.New("hostexec: this agent works in one folder, and a comm // ScopedText is the result of a call for a chat whose agent works in one // folder. -const ScopedText = "Not run: this agent works in one folder, and a command on this machine could read files outside it. Commands for this agent run only in the Sandbox add-on." +const ScopedText = "Not run: this agent works in one folder, and a command on this machine could read files outside it. Commands for this agent run only in an add-on that isolates them." // Run runs one call of bash for a in its chat's scratch folder. func (r *Runner) Run(ctx context.Context, a workspace.Actor, args json.RawMessage) (string, error) { diff --git a/core/services/studio/toolgroups.go b/core/services/studio/toolgroups.go index c0a5bcc1b0..381dae3bd1 100644 --- a/core/services/studio/toolgroups.go +++ b/core/services/studio/toolgroups.go @@ -154,17 +154,17 @@ func shellSwitched(c Commands, hidden map[string]bool) Commands { func shellReason(c Commands, buildReason string) string { switch c.State { case CommandsOff: - return "the Sandbox add-on is off for this chat" + return commandsPhrase(c) + " is off for this chat" case CommandsUnavailable: if c.Reason != "" { - return "the Sandbox add-on cannot run commands here: " + c.Reason + return commandsPhrase(c) + " cannot run commands here: " + c.Reason } - return "the Sandbox add-on cannot run commands here" + return commandsPhrase(c) + " cannot run commands here" } if buildReason != "" && buildReason != builtins.ReasonOff { return buildReason } - return "nothing here runs commands: no Sandbox add-on is installed and commands on this machine are off" + return "nothing here runs commands: no add-on that runs commands is installed and commands on this machine are off" } // filesNote is the line under the chat's file list when the chat has no diff --git a/docs/content/features/chats.md b/docs/content/features/chats.md index 1fa32f627a..7acc9d9e89 100644 --- a/docs/content/features/chats.md +++ b/docs/content/features/chats.md @@ -963,7 +963,7 @@ shown when the Sandbox is already installed, or when add-ons are off. server log has one line per command with the prefix `[host-exec]`. Administrators read the audit with `GET /api/chats/admin/host-exec/events` or the assistant tool `list_host_exec_events`. Lines older than - `chats_egress_audit_days` (default 30, the retention of the Sandbox network + `chats_egress_audit_days` (default 30, the retention of the command network audit) are removed daily; in a cluster one frontend does it, under an advisory lock. The file store also keeps at most 10000 lines. diff --git a/docs/content/features/runtime-settings.md b/docs/content/features/runtime-settings.md index baba52663c..e0216dce36 100644 --- a/docs/content/features/runtime-settings.md +++ b/docs/content/features/runtime-settings.md @@ -28,7 +28,7 @@ The groups reorganise the fields the page used to show under fifteen sections. T Search at the top of the page matches a setting's name, description and key, the group, and the old section name, so a search for "Watchdog" still finds the watchdog settings and each result says where it used to be. -`/app/settings?group=` opens a group (`memory`, `speed`, `backends`, `access`, `debug`, `agents`, `tools`, `swarm`, `look` or `addons`), and a hash after it brings a block of the group into view: `#settings-builtin-tools` (the built-in chat tools) on the Tools group. The old address of the Sandbox network, `/app/settings?group=tools#settings-egress`, opens the Settings tab of the add-on that holds it now (see below), or the Tools group when no add-on does. +`/app/settings?group=` opens a group (`memory`, `speed`, `backends`, `access`, `debug`, `agents`, `tools`, `swarm`, `look` or `addons`), and a hash after it brings a block of the group into view: `#settings-builtin-tools` (the built-in chat tools) on the Tools group. The old address of the command network, `/app/settings?group=tools#settings-egress`, opens the Settings tab of the add-on that holds it now (see below), or the Tools group when no add-on does. The settings of an add-on are not on this page: each add-on keeps them on the **Settings** tab of its details on the Add-ons page. When at least one add-on has settings, an **Add-ons** group at the end of the list names those add-ons, each with a link to its Settings tab. See [Host slots]({{%relref "features/addons#host-slots" %}}). An add-on can also ask LocalAI to draw some of LocalAI's own settings on that tab, with a [host control]({{%relref "features/addons#host-controls" %}}). The rule: this page keeps the settings of the features that exist without any add-on (the commands on this machine, the built-in web tools), and points to the add-on where an add-on serves them; the settings that exist only for an add-on are on its tab. The Sandbox network below is one: with the Sandbox installed, the Tools group shows a row that links to its Settings tab, and neither the group nor the search lists those settings. A built-in tool row that an add-on with the `tool-providers` control serves links to that add-on's tab. @@ -151,7 +151,7 @@ The **Tools** tab lists the built-in chat tools, from `GET /api/chats/admin/tool - **Search providers** (`chats_web_search_providers`, default empty): the providers of `web_search` in the order they are tried, comma separated: `searxng`, `duckduckgo`, `brave_html`, `bing_html`. Leave one out to never use it. Empty: `searxng` when an instance is set, else `duckduckgo,brave_html,bing_html`. An unknown name is refused. **Test search** on the `web_search` row says what each provider did (ok, challenged by a bot check, blocked, no results). See [Search providers]({{%relref "features/web#search-providers" %}}). - **Web pages may be on private networks** (`chats_web_allow_private`, default off): let `web_fetch` reach addresses inside your network. The cloud metadata addresses stay refused. Turn it on only if you trust every user of chats. - **Ports for web pages** (`chats_web_ports`, default `80,443`): the ports `web_fetch` may use, comma separated. A value that is not a list of ports is refused. -- **Sandbox network** (applies at the next connection of a command; an allow the proxy cached lives at most 30 seconds). The commands a chat runs in the Sandbox reach the network only through the proxy of the Sandbox add-on, and these settings bound it. They are on the Settings tab of the add-on that runs the commands (its `network-policy` host control), not on this page; `chats_egress_audit_days` is on both, since it also keeps the audit of the commands on this machine. They do not apply to commands on this machine (`chats_host_exec`), which have the network of the server. See [Network access]({{%relref "features/addons#network-access" %}}). +- **Command network** (applies at the next connection of a command; an allow the proxy cached lives at most 30 seconds). The commands a chat runs in isolation reach the network only through the proxy of the add-on that runs them, and these settings bound it. They are on the Settings tab of the add-on that runs the commands (its `network-policy` host control), not on this page; `chats_egress_audit_days` is on both, since it also keeps the audit of the commands on this machine. They do not apply to commands on this machine (`chats_host_exec`), which have the network of the server. See [Network access]({{%relref "features/addons#network-access" %}}). - `chats_egress_ceiling` (`off`, `registries` or `all`, default `off`): the widest preset any chat may use. `registries` admits the package registries only; `all` admits every public host. A chat chooses its own preset up to this. - `chats_egress_default` (`off`, `registries` or `all`, default `off`): the preset a new chat starts with, capped by the ceiling. - `chats_egress_allow_private` (default off): let a host that an administrator allowed, by a rule or a card answer, reach addresses inside your network. A preset alone never does, and the cloud metadata addresses and the server's own addresses stay refused. Turning it on needs `chats_egress_private_confirm` in the same request, with the phrase *I understand that commands can reach my private network*; the phrase is not stored. The add-on's Settings tab asks for it. With add-ons enabled the add-on owner checks the same phrase, so a direct `host-settings-update` call needs `chats_egress_private_confirm` in its patch too. diff --git a/pkg/egresspolicy/policy.go b/pkg/egresspolicy/policy.go index 116e7e082d..c12419bc22 100644 --- a/pkg/egresspolicy/policy.go +++ b/pkg/egresspolicy/policy.go @@ -45,7 +45,7 @@ func ParseEgressPorts(s string) ([]int, error) { } for _, p := range ports { if p == 22 || p == 25 { - return nil, fmt.Errorf("port %d is not allowed for the Sandbox network", p) + return nil, fmt.Errorf("port %d is not allowed for the network of commands", p) } } return ports, nil @@ -126,7 +126,7 @@ func splitAllowedHost(f string) (host string, port int, err error) { return "", 0, fmt.Errorf("%q is not a port", p) } if n == 22 || n == 25 { - return "", 0, fmt.Errorf("port %d is not allowed for the Sandbox network", n) + return "", 0, fmt.Errorf("port %d is not allowed for the network of commands", n) } return h, n, nil } diff --git a/pkg/mcp/localaitools/prompts/20_tools.md b/pkg/mcp/localaitools/prompts/20_tools.md index 2d5b759496..c088b76854 100644 --- a/pkg/mcp/localaitools/prompts/20_tools.md +++ b/pkg/mcp/localaitools/prompts/20_tools.md @@ -22,8 +22,8 @@ The MCP `tools/list` endpoint also exposes the full input schema for each of the - `list_shared_folder_events` — Read the audit of the shared folders, newest first. - `list_chat_tools` — List the built-in chat tools (bash on this machine, the web tools): on or off, who serves each, and the host-commands mode. - `list_host_exec_events` — Read the audit of the commands the chats' built-in bash ran directly on this machine, newest first. -- `get_chat_egress` — Read the network settings of the chats' Sandbox commands (ceiling, default, ports, registries, always-allowed hosts) and the requests of the last 24 hours. -- `list_egress_events` — Read the audit of the Sandbox network requests, newest first, with filters. +- `get_chat_egress` — Read the network settings of the chats' isolated commands (ceiling, default, ports, registries, always-allowed hosts) and the requests of the last 24 hours. +- `list_egress_events` — Read the audit of the isolated commands' network requests, newest first, with filters. - `get_branding` — Read the resolved instance name, tagline, and branding asset URLs. - `get_usage_stats` — Read token/request usage aggregates when usage tracking is enabled. - `get_pii_events` — Inspect recent PII-filter events without returning redacted request bodies. @@ -48,7 +48,7 @@ The MCP `tools/list` endpoint also exposes the full input schema for each of the - `toggle_model_state` — Enable or disable a model (`action`: `enable` or `disable`). - `toggle_model_pinned` — Pin or unpin a model (`action`: `pin` or `unpin`). - `set_branding` — Change the instance name or tagline. -- `set_chat_egress_ceiling` — Set the widest network preset any chat's Sandbox commands may use: off, registries or all. +- `set_chat_egress_ceiling` — Set the widest network preset any chat's isolated commands may use: off, registries or all. - `set_alias` — Create, update, or remove a model alias. - `seed_router_corpus` — Add validated labelled exemplars to a KNN router corpus. - `clear_router_corpus` — Permanently clear a KNN router corpus and its live index entries. diff --git a/pkg/mcp/localaitools/prompts/skills/manage_sandbox_network.md b/pkg/mcp/localaitools/prompts/skills/manage_sandbox_network.md index b80b3b500c..b9bb022678 100644 --- a/pkg/mcp/localaitools/prompts/skills/manage_sandbox_network.md +++ b/pkg/mcp/localaitools/prompts/skills/manage_sandbox_network.md @@ -1,13 +1,13 @@ -# Skill: Manage the network of the Sandbox commands +# Skill: Manage the network of the isolated commands -Use this when the admin asks whether chats can install packages, what the commands of the chats reached on the network, or wants to open or close the network of the Sandbox. +Use this when the admin asks whether chats can install packages, what the commands of the chats reached on the network, or wants to open or close the network of the isolated commands. The commands a chat runs in the Sandbox reach the network only through a proxy. Each chat has a preset: `off` (nothing), `registries` (the package registries, such as PyPI, npm, Go modules, crates.io, RubyGems, Maven Central and GitHub releases) or `all` (every public host). The ceiling is the widest preset any chat may use. Commands that run directly on this machine (the built-in bash) are not covered: they have the network of the server. -1. Call `get_chat_egress` first. Report the ceiling, the default of a new chat, whether a Sandbox add-on runs commands, and the allowed and blocked requests of the last 24 hours. +1. Call `get_chat_egress` first. Report the ceiling, the default of a new chat, whether an add-on runs commands, and the allowed and blocked requests of the last 24 hours. 2. To see what commands reached or tried to reach, call `list_egress_events`. Filter by `verdict` `block` to explain why a package install failed, or by `host` or `user`. Summarise; do not paste every line. 3. To change the ceiling, say what changes and wait for confirmation (safety rule 1). For example: "I'll set the network ceiling of the chats to **registries**, so commands can reach the package registries only — confirm?" Then call `set_chat_egress_ceiling`. Say that `all` lets commands reach any public host, which can carry the user's files out. -4. `get_chat_egress` also lists `allowed_hosts`: exact hosts (or `host:port`) that every chat with the network on may always reach, with the reason `allowed_host` in the audit. With the ceiling off they do nothing. You cannot change the list: tell the admin to edit "Always allowed hosts" in Settings > Tools > Sandbox network. -5. You cannot let commands reach private network addresses. That switch needs a typed confirmation: tell the admin to use Settings > Tools > Sandbox network. +4. `get_chat_egress` also lists `allowed_hosts`: exact hosts (or `host:port`) that every chat with the network on may always reach, with the reason `allowed_host` in the audit. With the ceiling off they do nothing. You cannot change the list: tell the admin to edit "Always allowed hosts" in Settings > Tools > Command network. +5. You cannot let commands reach private network addresses. That switch needs a typed confirmation: tell the admin to use Settings > Tools > Command network. 6. A user changes the preset of one chat in the chat's Tools menu, up to the ceiling. You do not change a chat's preset. 7. On an error, quote it verbatim (safety rule 3) and stop. diff --git a/pkg/mcp/localaitools/tools_chat_tools.go b/pkg/mcp/localaitools/tools_chat_tools.go index 9193a9734d..77f8488dd4 100644 --- a/pkg/mcp/localaitools/tools_chat_tools.go +++ b/pkg/mcp/localaitools/tools_chat_tools.go @@ -8,7 +8,7 @@ import ( // The built-in chat tools are the tools of the chats that an add-on may // replace: bash, which runs commands directly on this machine with no isolation -// when no Sandbox add-on serves it, and the web tools. Both tools here only +// when no add-on serves it, and the web tools. Both tools here only // read; an administrator changes the settings (chats_host_exec, // chats_tool_providers) in Settings > Tools. The same list carries the // built-in skills that installed add-ons replace, pinned in the same map. @@ -44,14 +44,14 @@ func registerChatToolTools(s *mcp.Server, client LocalAIClient, _ Options) { } // registerChatEgressTools exposes the settings and the audit of the network of -// the chats' Sandbox commands. Only the ceiling can be changed here; the +// the chats' isolated commands. Only the ceiling can be changed here; the // private-network switch needs a typed confirmation in Settings > Tools, and // the lists of hosts (extra registries, always-allowed hosts) are edited there // too: get_chat_egress reads them, no tool writes them. func registerChatEgressTools(s *mcp.Server, client LocalAIClient, opts Options) { mcp.AddTool(s, &mcp.Tool{ Name: ToolGetChatEgress, - Description: "Read the network settings of the chats' Sandbox commands: the ceiling (off, registries, all), the default of a new chat, " + + Description: "Read the network settings of the chats' isolated commands: the ceiling (off, registries, all), the default of a new chat, " + "whether private addresses may be reached, the ports, the extra registries, the always-allowed hosts (allowed_hosts), the audit retention, the package registries list, " + "which add-on runs commands and how, and the allowed and blocked requests of the last 24 hours.", }, func(ctx context.Context, _ *mcp.CallToolRequest, _ struct{}) (*mcp.CallToolResult, any, error) { @@ -64,7 +64,7 @@ func registerChatEgressTools(s *mcp.Server, client LocalAIClient, opts Options) mcp.AddTool(s, &mcp.Tool{ Name: ToolListEgressEvents, - Description: "Read the audit of the network requests of the chats' Sandbox commands, newest first: user, chat, host, port, " + + Description: "Read the audit of the network requests of the chats' isolated commands, newest first: user, chat, host, port, " + "verdict (allow, block, or done with the bytes moved) and reason. Filters by user, chat, verdict or host.", }, func(ctx context.Context, _ *mcp.CallToolRequest, args EgressEventsQuery) (*mcp.CallToolResult, any, error) { if args.Limit <= 0 { @@ -83,7 +83,7 @@ func registerChatEgressTools(s *mcp.Server, client LocalAIClient, opts Options) } mcp.AddTool(s, &mcp.Tool{ Name: ToolSetChatEgressCeiling, - Description: "Set the widest network preset any chat's Sandbox commands may use (chats_egress_ceiling): off, registries (the package registries only) " + + Description: "Set the widest network preset any chat's isolated commands may use (chats_egress_ceiling): off, registries (the package registries only) " + "or all (every public host). Lowering it applies within 30 seconds. Confirm with the user first (safety rule 1).", }, func(ctx context.Context, _ *mcp.CallToolRequest, args SetChatEgressCeilingRequest) (*mcp.CallToolResult, any, error) { out, err := client.SetChatEgressCeiling(ctx, args.Ceiling)