* fix(agent): give file tools the agent workspace as root when no workspace is set (#6679)
With no workspace bound, bash/python run in data/agent_workspace, but
RequestAuthority sealed no filesystem root, so every native file tool
failed with "requires a sealed resource root", and an approved
write_file failed with "no sealed resource identity". Seal the agent
workspace instead, and resolve relative paths in _resolve_tool_path
against it rather than the server's cwd.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* test: re-seal resource roots when a test swaps the authority owner (#6679)
A no-workspace authority now seals the agent workspace for its owner, so
replace(authority, owner="bob") copied alice's root and was rejected
before the approval-binding check the tests are about.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(agent): only seal a vetted agent workspace as the file-tool root (#6679)
Apply the agent_cwd() check before sealing data/agent_workspace: it must
be a real directory in the readable data subdirs, otherwise no root is
sealed. A symlinked workspace no longer redirects the file tools or the
bash/python launch scope. Tighten the dispatch test assertions to the
exact 'outside the sealed roots' message.
* refactor(agent): vet the no-workspace file root with default_agent_workspace (#6679)
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
#6683 made an exact approval seal a launch boundary (and a filesystem root)
in the request's workspace, but only when a workspace is bound. Agent mode
with no folder picked is the default, and there the approval still sealed
nothing, so "Allow" always ended in "Approved action has no sealed
process/job identity" (bash/python) or "Approved filesystem action has no
sealed resource identity" (write_file). In Docker every agent turn carries
the backend runtime context, so bash and write_file always ask for approval
and never ran.
With no workspace, seal the root in the agent workspace, which is where
agent_cwd() already runs bash/python in that case. Inherited (child)
authorities still cannot widen.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
cb052eee removed the caret that opens a backend's recipe panel, saying
the action had moved into the Installed menu, but that menu never got a
recipe item. The panel (model picker, commands, Run) could not be
opened, and the HW Fit / serve-card deep links that click the caret
only flashed the row. Render the caret again on every recipe row.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tracked HF collections also contain time-series forecasters, image
encoders and image/video generators. They were imported as "general"
LLMs and offered for vllm serve. Skip their pipeline tags; embedding,
reranker and RL-tagged LLM repos stay.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
_entry_from_collection_item parsed the repo name (the only source of the
"-A3B" active size) only when HF's numParameters was missing, which is
almost never. Every MoE model from the HF collection catalog was scored
as dense, with speed estimates 3-4x too low.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ToolApprovalStore.create() sealed a process identity only from the request
authority's launch scopes, which exist only for granted bash/python. For an
ungranted call the sealing failed silently, so the approval was created
without a process identity and the executor always refused it ("Approved
action has no sealed process/job identity"). When the authority is not
inherited and has no launch scope for the backend, seal one in the
request's single workspace root at approval time, as filesystem approvals
already do. Inherited authorities still cannot widen.
The skill test run and audit arm left their `async for` over
stream_agent_loop early when an approval was needed, without closing the
generator. asyncio closed it later from another task, so its ContextVar
resets raised "Token ... was created in a different Context". Close the
stream with aclosing, like the scheduler and teacher escalation do.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
dxrpl