IronClaw wants models to see only tools that can actually run

nearai/ironclaw issue #7836 is the inspected primary source: “Tool availability notice: filter by availability (installed + activated + credential-ready + authorized).” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- nearai/ironclaw issue #7836 was created 2026-08-23T20:21:59Z and was open at inspection; its title is “Tool availability notice: filter by availability (installed + activated + credential-ready + authorized).” - nearai/ironclaw PR #7833 was created 2026-08-23T19:51:16Z and was open at inspection; its title is “feat(suggestions): generate over the user's no-approval, read-only tools (#7812).” - nearai/ironclaw PR #7826 was created 2026-08-23T03:39:42Z and was open at inspection; its title is “Install the packages the hub publishes, and let the deep link land.” - The repository reported 12602 stars, 1536 open issues, default branch main, and last push 2026-08-23T22:59:12Z. - The latest tagged-release baseline checked was ironclaw-v1.3.0 published 2026-08-19T23:17:37Z.

What changed

nearai/ironclaw issue #7836 reports: Problem The model-visible tool surface (prompt schemas, namespace previews, and ironclaw.tool_search results) expose capabilities regardless of whether they can actually execute in the current deployment. The model then makes calls that are doomed before dispatch. Measured on PinchBench run 410dfedf (2026-08-22, permissive-bash arm of PR #7491): github.get_repo: 4 calls, 4 failures (no GitHub credential in the environment) builtin.ironhub_search: 8 calls, 8 failures ironclaw.memory.read: 2 calls, 2 failures task_image_gen burned much of its 1,500s budget searching the catalog for an image capability that does not exist in that environment, scoring 0 Every doomed call costs a full model round-trip (~60k input tokens at current context sizes), an error to reason about, and frequently a retry or an alternative-hunting detour. One unavailable tool in a parallel batch can trigger long recovery behavior (task latency, not just cost). This is not benchmark-specific: any production deployment without a given extension credentialed has the same dead ends. Rule expose a capability only when ALL hold: Applied uniformly at every disclosure layer: full schemas in the prompt surface, namespace previews, and tool_search results. Progressive disclosure (default Namespaces mode, ironclaw_loop_host::tool_disclosure_mode) controls how much the model sees; this issue is about filtering what is actually usable. Setup-flow exception:** a capability whose invocation produces a useful setup/approval flow (e.g. an OAuth launch card for an installed-but-unconnected extension) may stay

nearai/ironclaw PR #7833 reports: Closes #7812. Suggestion generation ran against a hardcoded four-capability allowlist, so cards were never grounded in the user's actual connected accounts — it could see that you *have* Gmail but never read a message. It now takes the run profile's surface narrowed by the user's **own** permission settings and to read-only effects. Approach One narrowing-only flag on the prepared-turn declarations, unattended_safe, plus two consuming builders on CapabilitySurfacePolicy. suggestion_tool_allowlist() is deleted. The approval decision is not re-derived.** authorize_visible_capability already runs the real 9-step gate per candidate — per-tool overrides, persistent always-allow grants, and the global auto-approve toggle whose default-on *is* the "system default is don't ask" the issue asks for. This change only sets the two inputs that gate already consumes. Declarations rather than a new run profile because the unbound lane has no alternative: unbound_turn.rs:215 sets product_context: None, so there is no TurnExecutionPolicy to carry it. A suggestion-scoped surface profile was tried and abandoned — accept_and_submit hardcodes requested_run_profile: None and coordinator.rs:377-386 rejects any non-unbound_default hint, so the arm would never fire; forcing it needs a *non*-unbound profile, which loses UNBOUND_DENIED_CAPABILITY_IDS ("a background run minting more background work is the runaway class this lane must not open"). #7498 built that shape and was closed unmerged; #7694 landed the declarations route the next day. One flag rather than two: the only combination

nearai/ironclaw PR #7826 reports: Summary Four catalog entries reach install and fail today: the legacy capabilities.json sidecar was mandatory, the artifact egress budget bounded the response instead of the outgoing request that max_egress_bytes measures, host-synthesized standard: schema refs were matched against published assets that no catalog publishes, and the install failure cause was discarded by the mapping layers. IronHub's "Install to Agent" button deep-links into the agent with a signed payload, and nothing here answered that link. Only an authenticated WebUI session could call the delivery endpoint and no route accepted the deep link, so a hub could register with an agent and then never deliver to it. That entry point is not the ironhub_install tool path: the caller is browsing the hub, not talking to the agent. The install page shows name, version, artifact digest and any private manifest source before the caller confirms. StaleTimestamp and Replay now carry distinct ProductSurfaceErrorKind values so the page can say which one happened rather than reporting a generic 403. The page's English copy ships in a lazy sidecar rather than en.ts, which is bundled eagerly on every route and leaves /chat roughly 400 gzip bytes under its ceiling. For the same reason the page uses local state instead of react-query, which split a shared QueryClientProvider chunk into that closure. Change Type [x] Bug fix [x] New

Why it matters

Tool discovery is an execution promise. Exposing unavailable or mutating capabilities wastes context and can hand unattended runs authority they were never meant to hold. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-24. The tagged-release baseline was ironclaw-v1.3.0 published 2026-08-19T23:17:37Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/nearai/ironclaw/issues/7836. Supporting records are https://github.com/nearai/ironclaw/pull/7833 and https://github.com/nearai/ironclaw/pull/7826. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Derive the visible surface from host state, keep setup-capable exceptions narrow, pin read-only effects at staging, and show signed install details before approval. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.