With authentication off every caller that reaches the port is the same
local owner, and the checks that tell a person from a script are
headers the caller chooses. Any process or agent that could reach the
port could grant host operations, set deny rules and turn the blanket
approval on.
UI host grants are now locked by default in that mode. The policy file
and flags still grant, and every write route answers 403
locked_by_deployment with a sentence that says why. The overview and the
preview carry the lock and its reason for the page. The new flag
--addon-host-ui-grants-without-auth turns the UI grants on knowingly and
logs a startup warning. With sign-in on nothing changes.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt
The UI grants of an add-on name the storage and the add-on ID. A plain
upgrade through dispatch could resolve to a package from another
configured library or signer and inherit every grant without a person
looking at it.
An install or upgrade without an approval is now held when its package
comes from another library or signer than the installed one, like an
upgrade that asks for more operations: the old version keeps running
and the refusal says to approve in the browser. A request that carries
an approval for the exact digest goes through.
Uninstall deleted the grants after the journal commit and only logged a
failure, so a reinstall under the same ID before a restart could meet the
old entry. The grants are now deleted before the commit, and a failure
stops the uninstall with the add-on still installed.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt
Staging the grants of an install now goes through Store.UpdateAudited, so
an install fails and the document stays as it was when the audit line
cannot be written.
A write from an API key, an MCP session or a tool call was refused in the
HTTP layer before it reached the owner, so the refusal left no audit line.
The route now hands the refused write to the owner without the human
mark; the owner refuses it and records the credential kind, never the
credential.
Manager.HostGrantsChangedReport names the add-ons the re-sync started or
stopped, and the owner writes a restart-for-grant line for each. The
event constant was never used before.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt
Revoke, an edit that only removes, a deny rule change and a blanket
switch-off with revoke never asked the manager to look again, so an
add-on that lost a required operation kept running, and one that was
refused for a deny stayed refused after the deny was lifted. Each of
these routes now calls the refresh hook, as the grant routes did.
The audit lines of these writes were discarded on error, so a grant
could exist without its record. Store.UpdateAudited runs the audit
append after the patch is validated and before the document is
written. When the append fails nothing is written and the route
answers 503.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt
Stage copied the blanket mode that a flag fixes into host-grants.json
at the first install. After the flag was removed the document still
said "any", so the switch stayed on without anyone typing the
confirmation text.
The deployment mode is now applied at read time only. The document keeps
what a person set, and a grant made under the flag records revision 0,
which the validator accepts for a blanket grant of the deployment.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt
A memory note is still a proposal that the person confirms by default.
An add-on can declare the user setting with the role memory.save-mode,
and the person then picks: ask first, save it and tell me, or never.
With auto, a note from the person's own Studio chat is applied at once
through the whole proposal path (grant, gate, checks, rate limit, audit)
and confirmed as the person, so it is one change set that revert_change
and the Undo on the chat restore. The chat shows "Saved to memory" with
Undo and no confirmation card. The record carries auto: true and the
audit says the write was automatic.
Safety rules live in the host. A connector chat always asks, a trigger or
job has no tool, a saved agent cannot widen the choice, and a failure to
read the setting asks. At most 5 notes are saved unasked in a turn; a note
over 4 KiB or one that looks like it holds a secret becomes a normal
proposal. With never the memory kind is hidden from propose_change and a
stray call is refused. Only memory reads the setting.
Assisted-by: Claude:claude-sonnet-5-5 go node playwright
An add-on can declare userSettings in its manifest: a key, the allowed
values and a default. The host keeps each person's answer in the account
database every frontend shares (one file when accounts are off), checks
every write against the declaration, and never asks the add-on.
GET and PUT /api/addons/{id}/user-settings read and write them. A write
needs the person's own browser session, so no API key, model or tool can
change one. A setting may carry a role that the host reads for its own
rules; the host fixes the values and the default of a role so a manifest
cannot loosen it. Pages reach their settings through sdk.userSettings,
which is bound to the add-on that calls it.
Assisted-by: Claude:claude-sonnet-5-5 go node
A chat now enables a set of connections for an add-on whose tools run with
a credential, and the model names one of them in each call. This applies to
every add-on that declares a credential in its manifest.
- The Tools menu row of the add-on lists the connections with a checkbox
each. The saved agent names a set too (an empty set means each chat
chooses). A chat that a connector binding started keeps that binding
alone. With one connection, it is the set. With none enabled, the tools
are not offered.
- With one connection enabled the tools are unchanged. With two or more,
the host adds a required `connection` argument to every tool of the
add-on in the definitions it gives the model: an enum of the connection
names (the display name folded to lower case, digits and hyphens; the
description keeps the display name). The add-on never sees the argument.
- The name is checked against the set the chat has now, not against all the
connections of the person. A missing or unknown name returns a sentence
that lists the allowed names, and nothing is sent. A write tool never runs
without the name. Text in a tool result cannot widen the set, and the
owner checks the chosen binding against the set again.
- The resource list of the named connection is the only one that applies.
Results, the approval card and the text for a pending change name the
connection; the audit line has the binding ID.
- A connection name must be unique per person and add-on among the
credential-only connections, compared by name fold. Older duplicates get
a numeric suffix in the model's list.
- The stored chat, draft and agent values move from one binding ID per
add-on to a list of IDs. A single string is read as a set of one in the
stores and in every request, so older data and clients keep working.
PUT /api/chats/{id}/connections takes `connections`; the older
`connection` field still works.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt ginkgo node eslint playwright swag
The host access page needs the verified requests of each installed
add-on, the operation that completed its generation, optional operations
an upgrade added, and an upgrade that waits for approval. It also needs
to read a release's manifest without installing it. Add both to the
manager. An automatic upgrade that is held for approval is remembered.
Assisted-by: Claude:claude-sonnet-5-5 go
View hides a closed or doubtful store behind an empty document, which
would drop the deny rules kept in it. A caller that must fail closed asks
Usable first.
Assisted-by: Claude:claude-sonnet-5-5 go
The Authority binds a grant to the identity of the installed package. It
runs inside admission, which holds the manager lock, so it needs a read
that does not take that lock. Keep the identities beside the completed
operations and update them when an operation applies.
Also export the check for the URL of the official library, which the
blanket approval needs to tell the official library from a source an
administrator named the same.
Assisted-by: Claude:claude-sonnet-5-5 go
An upgrade adds operations to an entry that already holds others. With one
operation ID per entry, the whole entry went pending until the upgrade
completed, so the running old version lost its grants for that time, and a
crash removed all of them.
Give an operation its own optional operation ID. Only that operation waits
for its lifecycle operation, and reconciliation removes only what an
unfinished upgrade added.
Assisted-by: Claude:claude-sonnet-5-5 go
A chat never uses a connection that the host picked for it. For an add-on
whose tools run with the token of a connection (such as GitHub):
- With one connection, it is selected. With several, the Tools menu row
of the add-on has a Connection selector, and until the person picks one
the tools are not offered and the row says so. With none, the row says
so and links to the Connectors page. The choice is stored with the chat
and its draft, like the other switches, and follows a fork, a
sub-agent and the runs of a trigger the chat proposed.
- A saved agent can name its connection per add-on (agent form field, API
field connections). Its chats use it, show it read only and cannot
change it. An agent with no choice follows the same rule as a chat. A
chat that a connector binding started keeps using that binding.
- CredentialFor takes the selected binding and uses only it, so the
resource list of that binding is the only one that applies. A call with
no selected binding is refused with the code select_connection and a
note the model can relay. The first-match code (connectors.Pick) is
removed.
- Tool results and proposal cards say which connection acted, for example
"as Work, repository acme/widgets". A proposal is applied with the
connection it was previewed with. The credential use is logged with the
binding ID.
Contract: the credential slot takes an optional resourceLabel (the word
for the resource in that line). The agent export file does not carry the
connections, since a binding ID belongs to one server.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt ginkgo node playwright protoc swag
The confirm header names what the administrator acted on: addonId@digest
for an install, the add-on ID for an edit or a revoke, "blanket" and "deny"
for the two switches. The operation ID is optional on every write but the
install; the receiving host makes one when the caller sent none.
Preview and page statuses are allowed, not_allowed, blocked or unsupported
in both. A preview names what an upgrade adds, using the identity of the
installed package. The page carries the library, the new optional access and
the required operations that keep an add-on from running. "keep" relabels
named blanket grants as the administrator's own. The blanket switch ignores
scope options when it is off.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt ginkgo swag
The owner now serves the host access calls: read the grants, preview what an
install would ask for, install or upgrade with an approval, edit or revoke
the grants of one add-on, change the blanket approval and the deny rules.
Every write needs the human surface mark and is refused when the deployment
locks the store. Typed refusals (revision_conflict, approval_stale,
blocked_by_policy, locked_by_deployment and others) cross the carrier
unchanged, so every frontend gives the answer of the owner.
A frontend carries the mark as a signed field of the forwarded request, and
only for a host access call. The owner honors it and nothing else: a
frontend with its own flags or store still forwards, and an owner without the
calls is reported as unavailable with its reason.
The preview issues a single-use nonce bound to the credential, the add-on,
the package digest and the grants revision. The install must present it.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt ginkgo
The handle leaves the table before the audit hook runs, so a loaded
machine could read the list too early. Wait for the outcome.
Assisted-by: Claude:claude-sonnet-5-5 go
An administrator can now grant host operations when an add-on is
installed or upgraded. The manager checks the approval against the
package it actually stages: the digest must match, and only operations
the verified manifest declares and the host registers are granted, never
a denied one. A required operation that is neither held nor approved
refuses the install with approval_required, or blocked_by_policy when a
deny rule forbids it. An upgrade that needs more required operations is
held and the old version keeps running. Optional operations are never
granted without approval, and a manifest that asks for fewer operations
shrinks nothing.
Grants are written to a GrantStore before the journal commits the
operation and removed if it fails, and they count only once the
operation completed. Uninstall deletes them after the journal. A start
reconciles the store with the journal. The automatic upgrade never
approves; only the blanket hook of the store can. HostGrantsChanged
stops an add-on that lost a required operation and retries one that was
refused.
Assisted-by: Claude:claude-sonnet-5-5 go
The install dialog and the host access page need a title, one sentence
and a risk word for each operation an add-on may ask for. Add
DescribeOperation next to the supported list, and a test that fails when
an operation has no description.
Assisted-by: Claude:claude-sonnet-5-5 go
An expiry ended a file handle while a put created the pipe and its
cancel function, which the race detector reports. The expiry must not
wait for a put that holds the handle lock, so guard the two fields with
a small lock of their own.
Assisted-by: Claude:claude-sonnet-5-5 go
The broker copied the allowed prefixes when an add-on started, so a
change of grants needed a restart of the add-on. Take an Authority
instead and ask it on each call: a revoke or a deny applies to the next
call, and a call that already runs finishes. A refused call answers the
same text whatever the reason; the reason goes to the log.
The supervisor opens the host endpoint when the add-on holds an
operation or its manifest declares one, so an add-on with an optional
operation and no grant starts degraded and a later grant works at once.
The broker now exists whenever the add-on manager does. The manager,
the apps list and the tool filters read the same Authority, which is the
startup policy until another one is set. Admission also tells a denied
operation from a missing grant.
Assisted-by: Claude:claude-sonnet-5-5 go
The audit hook runs on the goroutine that closes a transfer while the
spec reads the list, which the race detector reports. Read the outcomes
through a locked copy.
Assisted-by: Claude:claude-sonnet-5-5 go
A connector kind can declare agentOptional. A binding of such a kind may
have no agent: it holds the token, the resource list and the write mode
for the tools of a chat, and never receives or answers a message. The
GitHub kind declares it, so a person no longer makes a throwaway agent
only to store a token.
Without an agent the host refuses every setting that needs one:
listening, accepting senders, an allowlist, a notification chat,
talk-back channels, permissions, pairing and trigger approval. The
places that read the agent of a binding handle the empty value:
inbound routing, the polling loop, notifications, pairing, the capability
check (deny by default) and the grant switch. A kind that does not
declare the key still needs an agent on every binding.
The binding page makes the agent field optional for such a kind with
help text, and the list shows "Credentials only".
Assisted-by: Claude:claude-sonnet-5-5 go gofmt ginkgo node protoc swag
A poll that began before the add-on stopped could still be counted, so
the spec for a binding without its add-on failed at times. Take the
count after a short quiet and require that it does not grow.
Assisted-by: Claude:claude-sonnet-5-5 go ginkgo
NewAuthority reads the store on every call through an immutable view, so
a UI grant, revoke or deny applies to the next host call without a
restart. The file and flag deny rules do not depend on the store.
Assisted-by: Claude:claude-sonnet-5-5 go
The hostgrants package holds the owner document of host operation grants
made in the UI, the UI deny rules, the blanket switch and the hints used
to pre-tick a reinstall. Writes use compare-and-set on a revision and
operation receipts, with atomic persist like the host settings store.
The package also holds the pure policy logic: deny (file, flag, UI) over
file prefix grants over exact UI grants, with identity and pending-entry
checks, the grant plan (approved, declared, registered, not denied),
blanket evaluation, startup reconciliation and an fsynced audit file.
Assisted-by: Claude:claude-sonnet-5-5 go
Bindings saved before permission enforcement have an empty capability
list, so file upload, triggers, memory and talk-back stay denied until
the owner sets them. Give those bindings the set that "Allow the usual"
grants, one time.
An empty list is stored the same whether the owner never chose or
cleared every switch, so the store keeps a migration record instead of
a flag on each binding. The record is claimed atomically with a lease,
so several frontends starting together run it once, and a finished
record is never claimed again: later empty lists are the owner's choice.
Each binding is written only while it still has no capabilities, so a
save made at the same moment is not overwritten.
Only bindings whose kind is running and lists permissions are changed;
sensitive capabilities are never granted. One log line per binding and
one summary. LOCALAI_SKIP_BINDING_CAPS_MIGRATION skips it.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt protoc
The broker, the supervisor and the manager each copy the grant map at
start. An Authority answers what an add-on may call right now, so a
later change can apply to the next call without a restart.
Add the interface, the Reason type and EffectiveSet, with a static
implementation over today's prefix map. Nothing uses it yet and
behavior does not change.
Assisted-by: Claude:claude-sonnet-5-5 go
A trigger run with nobody present only reads unless its trigger holds
act.* grants, and until now only the REST API could set them. An agent
that proposes a trigger can now ask for acts too:
- propose_trigger takes an optional acts list. The names must be
act.* grants the agent of the chat holds; anything else is refused
and nothing is stored. A read_only proposal cannot carry acts.
- The proposal stores the list. Confirming it, in Studio, by a plain
yes or by confirm CODE, grants exactly that list. No tool changes
the acts of a trigger afterwards. Two proposals that differ only in
their acts are kept apart.
- The text of a proposal in a messaging app now has a Permissions
line, in plain words with sensitive classes marked: read only, or
what a run may do. The confirmation repeats it. A proposal that asks
for acts is never set up without a yes, whatever the approval mode.
- The trigger REST object gains acts_held, read_only and
read_only_why, computed with the same rules as the run, so a client
can show why a run only reads.
Assisted-by: Claude:claude-sonnet-5-5 go ginkgo
A new chat with the sandbox switched off in the composer showed no
"switched off" notice. GET /api/chats/draft/addons took only the model
and the agent, so it always reported the default commands state.
Accept the draft's switches as comma-separated query parameters
(addons_off, builtins_off, builtins_on), check them as the create request
does, and apply them to the draft record before the commands state is
worked out. The composer sends its choices each time an add-on or a
built-in group is switched, so the notice follows the switch.
Assisted-by: Claude:claude-sonnet-5-5 go-test playwright
An agent with no grant list keeps its non-sensitive connector features
(trigger tools, talk-back, files from senders). Granting any one built-in
makes the list the whole answer, so the others stop working. The editor
had no grants list at all, so nobody could see this.
Add a Permissions section to the agent editor with the declared grants.
When the first grant is ticked on a saved agent that had none, a notice
names the connector grants that would turn off and a button adds them.
Also fix the files.upload text. The gate enforces it on files a sender
attaches to a message, not on the agent sending files out, so the grant
is now "Receive files".
Assisted-by: Claude:claude-sonnet-5-5 go-test playwright
Connecting a connector must reach both MCP transports. Adds specs that resolve a
Streamable HTTP server promptly and a legacy SSE server, through the same
mcptransport.Connect path that agent runs use.
Signed-off-by: rossg <ross@golder.org>
(cherry picked from commit 4feaf9db39)
(cherry picked from commit fab3cfa21c13747e03115d7cc39f2466962f16e8)
A trigger run or an agent job has nobody to approve a step, and so far
the approval mode auto_readonly and the act.* grants were only recorded.
The prompt was the only thing that kept such a run from acting.
Every tool call of an unattended run now goes through one check at the
call. A tool that only reads runs. Any other tool needs the grant of its
class, and the check fails closed:
- act.files for write_file, edit_file, move_file, delete_file and the
built-in bash;
- act.addons, or act.addons:<id>, for add-on tools whose declared kind is
not read, plus act.spend when the add-on gates the tool with a
permission;
- act.spend for MCP tools.
A trigger holds its new acts list within the grants of its agent. A
trigger that declared read only runs, or that a binding in auto_readonly
mode made without asking, is refused every non-read tool whatever it
holds. A binding that cannot be read counts as auto_readonly. A job
holds the act grants of its agent. Sub-agents follow their parent, and a
saved agent cannot be started from an unattended run.
A refused call answers with a plain sentence the model can pass on, not
an error, and writes one audit log line. Triggers set acts through the
REST API; a model never can. A trigger whose plan names a file it writes
keeps act.files.
Assisted-by: Claude:claude-sonnet-5-5 go ginkgo swag
The Skills page asks for the skills of the saved agents with
agents=true and shows them with the agent's name. A skill of the
agent layer says who proposed it, can be removed (to the Trash) and
is not offered to other agents. The list of a plain chat or of the
agent form never carries them.
Assisted-by: Claude:claude-sonnet-5-5 go node
A saved agent keeps its own skills in LocalAI/agents/<agent>/skills.
Only a chat that runs that agent sees them. They sit between the folder
and personal layers, so an agent's version of a skill wins for that
agent, and they count as granted without being listed in the agent's
skills.
An agent writes one by a skill change proposal, as before; the new
layer only reads them. A proposal for an agent skill cannot take the
name of a core skill or of a document slot (read from slots.json).
When writing-skills loads in a chat of a saved agent it starts with
"Do not write files. Call propose_change with kind skill.", and the
skills.write grant makes it visible to the agent.
The Skills list gains the agent layer, with the agent's ID and name,
and a skill can be read or removed (to the Trash) with the agent
query parameter.
Assisted-by: Claude:claude-sonnet-5-5 go swag
The draft tools and add-on lists, and the tools list of a stored chat,
read the execution status without an execution scope. The host logged
an error and reported the status as not selected. They now run in a
scope; a draft has no conversation, so its status says "draft".
In the Home composer, switching a built-in tool group on or off reset
the commands state to the loading value and never read it again. The
composer then showed the unknown warning for good. The Hide button also
did nothing for that state, because it needed a binding identity that
the loading value does not have. A draft now keeps the state the list
gave it, and Hide works for any notice that is shown.
Assisted-by: Claude:claude-sonnet-5-5 go ginkgo node
A connector add-on no longer carries file bytes in the connector
envelope. The ops media and send_file need a transfer handle, and the
gateway refuses a call to them without one, or for a kind that declares
no files.
- The manifest field files.transfer, the inline file of a request and
of an answer (ConnectorFile) and the 1 MiB cap
(MaxConnectorFileBytes) are removed. The 2 MiB limit of a connector
call between hosts drops to 1 MiB, because it holds text and no file.
- A kind that declares no files moves no file: the host answers a sender
who attaches one with a plain sentence and does not offer attach_file.
A direction left out of a declared files block still gets the host
ceiling.
- The inline layer is gone from the file limit, from the API
(inline_bytes) and from the Files section of the connector page.
- The Telegram and Slack add-ons keep only the streaming paths. The
tests moved to the handle path, and the studio test rig gives every
connector add-on a table of handles.
Assisted-by: Claude:claude-sonnet-5-5 go test node
No release carried add-ons, so nothing reads older add-on data or
manifests. Delete the code that did.
- Connectors: the kind and the add-on of the Telegram connectors that
core once carried are gone (LegacyAddon, KindTelegram, the stored
binding normalization, the platform titles). A binding needs a kind,
and its add-on is the one that serves the kind. The conversion of the
old agent pool lists every connector as dropped instead of making a
Telegram binding, and its notes say so.
- The library index reads only the id field of an entry, not addonId.
- A host control that has a capability block (the network policy) is
attached by that block alone, not by a tool that replaces bash.
- The Office create tools no longer answer for the argument names of an
earlier schema, and the identity file note about old addresses is
gone.
- The known debt of the provider-name guard drops the entries of the
conversion and of the resource listing shim, and its ceiling goes
from 13 to 5.
Assisted-by: Claude:claude-sonnet-5-5 go test
No release ever shipped add-ons, so there is no installed base on api 1.
The manifest must now declare api {"min": 2, "max": 2}; a manifest with
api 1, no api or a wider range is refused with a message that names the
range.
Every field that was gated on api 2 is now part of the contract, so the
Min*API constants and their gates are gone, and so are HostAPIMin and
the apiMin host field. Three older-manifest shims go with them: the
resource listing the host implied for one add-on, the legacyArgs hint
for arguments an older version of a tool took, and the tests that
checked the gates. All shipped manifests and the test fixtures declare
api 2.
Assisted-by: Claude:claude-sonnet-5-5 go test
For a kind that declares files.transfer, the connector manager gives the
add-on a handle and not the bytes, in both directions.
Inbound, the add-on streams the file to the host. The chat upload then
reads it from the blob store, so a 6 MB PDF reaches the chat. Outbound,
the manager checks the access of the chat to the file, gives the
process that runs the add-on only the hash and the size of the content,
and the add-on pulls the chunks. The file limit of such a kind has no
inline cap: it is the smallest of the host ceiling, the ability the kind
declares and the limit the owner set for the bot, and the sentence names
the number and the layer. A kind without transfer keeps the 1 MiB inline
cap, and its sentence says so.
Checks: the files of one message may add up to three times the limit;
the media type that the add-on states must be among the types the kind
declares; an outbound file must have a type that the kind declares and
must not start with an HTML page. Every transfer writes one audit line
with direction, binding, size, result, layer and time, and no name or
content. The binding page no longer says "larger files need streaming"
for a kind that streams.
The specs run the real Telegram and Slack add-ons, the real gateway and
the real file operations over scripted platform APIs, with a 6 MB file in
each direction.
Not in this change: a daily byte counter per binding, and a virus scan
(the table has a hook that accepts everything).
Assisted-by: Claude:claude-sonnet-5-5 go test
A connector add-on that declares files.transfer no longer carries file
bytes in the connector envelope. The host puts a random handle in the
request of the op media (write) or send_file (read), and the add-on
streams the file with two new host operations, connector.file.put and
connector.file.get, in chunks of at most 256 KiB.
The process that runs the add-on registers the handle when the call
arrives and ends it when the call returns. A handle is bound to the
add-on, so another add-on gets the same answer as for an unknown
handle. An unfinished inbound file is dropped with its partial bytes,
and a handle with no call for two minutes expires. Inbound bytes go
to the blob store of the workspace, outbound bytes come from it, so a
cluster needs the shared object store and no shared disk. The file is
never held in memory. The host overwrites the size and hash of an
inbound file with its own record.
The change is additive: the field files.transfer needs manifest API 2,
a kind without it keeps the inline path and its 1 MiB cap, and the host
never sends it a handle. A call that carries a handle may run up to 15
minutes. The ceiling of a file also stays under the largest file of a
workspace.
Assisted-by: Claude:claude-sonnet-5-5 go test
The grants of an agent were stored and listed, but only the proposal kinds
read them. The connector gate now reads them too, so a tool exists when
the sender holds the capability on the binding, the agent holds the grant
and the chat did not switch the tool off.
It covers triggers.propose, triggers.run, talkback.channels,
talkback.new_channel and files.upload. Every question that goes through
the gate asks the grants: the capabilities of a turn, the check of a
feature that has a sender, and a run without a sender, so a trigger that
fires from a message pauses when the grant goes.
An agent with no grant list keeps the capabilities that are not
sensitive, as before. A sensitive one (talkback.new_channel) needs the
explicit grant. Once any grant is on the list, the list is the whole
answer. The act.* grants are not enforced: the action policy of unattended
runs that uses them does not exist yet.
Assisted-by: Claude:claude-sonnet-5-5 go test
A write tool of an add-on that holds a credential was protected only by
the write mode of the connection and the confirmation of the proposal.
In a connector chat it now also needs the capability tools.write for the
sender of the turn, through the same Authorize path as the other
capabilities: the tool is not offered without it, a call is checked again
and every decision is audited. The default is no.
The rule is by shape, not by name. The manifest says an add-on holds a
credential, and contract.ToolPermission maps its non-read tools to
tools.write. The chat reads the permission from the tool definition, so
the core names no add-on.
Also close a hole in local-owner mode, where a chat turn and the browser
share one credential: a proposal that waits for a person could be
confirmed from a chat turn. The call of a chat tool now carries a mark,
and the owner refuses to confirm such a proposal under it. A remote owner
does not see the mark; local-owner mode has no remote owner.
Assisted-by: Claude:claude-sonnet-5-5 go test
One manifest-driven guard replaces the Go-only provider guard. It reads
addons/*/manifest.json and fails when the Go strings of core and pkg,
the React UI source, the locale files or the core docs hold the id of an
add-on with a role (as a whole string or a tool-name prefix) or one of
its declared titles as a whole word.
Third-party mentions (OAuth login, release sources, token formats) and
ordinary words sit in a commented allow-list. The special cases that
remain (propose_change memory kind, the Account memory tab, the Telegram
conversion, the Tables listing shim) sit in knownDebt, each with the item
that removes it, and a ceiling that only goes down.
Reword the sandbox sentences in the container docs and use neutral
sample names in the UI catalog page.
Assisted-by: Claude:claude-sonnet-5-5 go test
The provider guard flags any core string that contains the name of a
shipped add-on that provides a generic role. The web add-on has the id
and title "Web", so the built-in tools group titled "Web" in the tools
picker (and the schema example for it) failed the guard on master.
Rename the group title to "Look things up online", which matches its
"cannot look anything up online" off-state text. Update the schema
example and the Playwright fixtures and specs that read the title.
Assisted-by: Claude:claude-sonnet-5-5 go test eslint
"Do it in 10 minutes" and "at 18:00" now work from a connector chat. The
agent proposes a timer with when {"in": ...} or {"at": ...}; it runs
the model once, reports to the chat it was set in, and is removed, also
when the run failed. A timer is at least one minute and at most a year
away. Recurring triggers keep their one-hour floor. Every proposal and
confirmation text states the cost: one model run.
A proposal is answered with a plain word in the same thread: yes, ok,
no, cancel. The code stays as a fallback when several proposals wait.
Only the whole message of an allowed sender counts, and only when the
capability gate allows it, so nothing the agent read can approve.
The approval setting of a binding now takes effect. In auto mode the
trigger is made at once and the chat is told how to cancel it; in
auto_readonly mode that holds only for a proposal that says its runs
only read. The owner's limits bound it, and a proposal over a limit is
asked instead, with the reason. Recurring triggers made this way end
after the lifetime.
Assisted-by: Claude:claude-sonnet-5-5 go
A connector binding gets an approval setting: ask, auto or auto_readonly,
with four limits for the two automatic modes (live triggers, minutes
between runs of a recurring trigger, runs a day, lifetime in days). The
setting is generic, so every connector add-on can show it, and the
shared connector page of the add-ons now draws it. A binding that sets
nothing asks, as before.
This change stores, validates and exposes the setting. The next change
acts on it.
Assisted-by: Claude:claude-sonnet-5-5 go swag node
A saved agent now has a Builtins list: the capabilities its owner gave
it (memory.write, profile.write, skills.write, pages.write,
dashboard.write, triggers.propose, triggers.run, talkback.channels,
talkback.new_channel, files.upload, act.files, act.addons, act.send,
act.spend and the opt-in group saved_agents). The list is empty by
default, and nothing turns a grant on for a template, an import or a
write that omits the field.
A chat of the agent holds the grants the user may use at the turn
(agent scope). A tool exists when the grant is held, the chat did not
switch its group off and the run can hold rights: a sub-agent or a run
that started by itself never does. propose_change and revert_change
now exist only for a chat that holds the grant of at least one kind,
and the schema lists only those kinds.
propose_change gains the kinds skill, page and dashboard. A skill is a
SKILL.md for the personal or the agent layer, and a skill with
locked: true is refused, also as a shadow of a locked personal skill.
A page is a set of files checked against the Pages rules and written
as one change set. The dashboard is a home.json checked against its
schema. All three are re-checked when the owner confirms or edits.
GET /api/chats/agents/builtin-grants lists each grant with its title,
description and sensitive flag. The agent record, the write body and
the export file carry builtins; an old file imports as before and an
unknown name is dropped in an import and refused in a write.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt swag
A connection now has a write mode, chosen on the add-on page: off (the
default), propose (each change waits for the person to confirm) or auto
(a chat of the person makes it at once). The host enforces it for every
write tool of an add-on that holds a credential, before the add-on is
called, and holds the call to the repository list of the connection.
Host:
- Binding.WriteMode, stored in both stores and in the connector API
(write_mode). Absent means off, so existing bindings stay read only.
- A credentialed add-on may declare write tools. They name the resource
with the credential slot argument, never resourceId. A tool can set
approval "always", a ceiling that keeps a proposal even in auto.
- The proposal broker fetches the credential for the preview and again
for the apply, so it is never stored. A mode lowered between the
proposal and the confirmation refuses the apply. A proposal that
awaits a person cannot be confirmed by a chat turn.
- New capability name tools.write for the roles a connector kind
declares.
Add-on, tools (kind write): comment-issue, comment-pr, create-issue,
edit-issue (title, close or reopen), add-labels, review-comment-pr.
They preview plain facts, refuse a stale target, cap and screen the
text for secrets, and keep a receipt journal plus a hidden marker in the
text, so a change whose answer was lost is not sent twice.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt ginkgo node
The registry spec knew every built-in tool by name. send_message is
governed by the capability of the binding and the operator switch, so it
has no group and no setting.
Assisted-by: Claude:claude-sonnet-5-5 go
The four document skill names were code in the contract, the hint for
binary files kept its own list of formats and libraries, and the chat
boundary rewrote the old arguments of one add-on by its ID.
A skill that shadows a name can now declare the slot it serves: kind,
file extensions, name words and a library hint. A tool can declare
legacyArgs, the arguments it refuses now, each with a hint. Both need
manifest api 2. The four default slots move to a data file that the
contract reads, so a manifest that declares nothing keeps working.
The host takes the replaceable names, the files a skill covers and the
hint for a script from the skills the add-ons list. It compares no
format or add-on ID. A guard spec fails when it does again. The Office
manifest declares its slots and legacy arguments and accepts api 2.
Assisted-by: Claude:claude-sonnet-5-5 go gofmt
Ettore Di Giacinto