IronClaw

IronClaw repairs device-link guidance across extension setup

IronClaw proposes restoring device-link guidance lost in an extension refactor, while reports show camelCase MCP tools can disappear from discovery and Telegram offers an account-link path it cannot complete.

← Back to homeOriginal source ↗

nearai/ironclaw PR #7861 is the inspected primary source: “fix(extensions): restore device-link setup guidance orphaned by #7766.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- nearai/ironclaw PR #7861 was created 2026-08-25T00:33:33Z and was open at inspection; its title is “fix(extensions): restore device-link setup guidance orphaned by #7766.” - nearai/ironclaw issue #7856 was created 2026-08-24T18:59:06Z and was open at inspection; its title is “MCP tool discovery silently skips camelCase tool names.” - nearai/ironclaw issue #7853 was created 2026-08-24T18:06:26Z and was open at inspection; its title is “Telegram setup offers personal account linking but cannot complete it (missing tool).” - The repository reported 12604 stars, 1533 open issues, default branch main, and last push 2026-08-25T00:33:20Z. - The latest tagged-release baseline checked was ironclaw-v1.3.0 published 2026-08-19T23:17:37Z.

What changed

nearai/ironclaw PR #7861 reports: What broke "lets setup telegram" → the workspace bot activates → the agent offers to also link your personal Telegram account → you say yes → the agent replies that it "still can't link a personal Telegram account from here because there's no available tool for that step."* The agent's self-report is **true**: no model-visible capability starts a device-link flow, by design (the ceremony renders a scannable code and asks for a one-time code and an account password, so it cannot run from chat). The defect is that the model was told to offer it. Root cause — a mechanical regression of #7766 ExtensionLifecycleManager::package_declares_device_link_user_link decided whether the model is told "linking happens in the Web UI". It delegated to device_link_channel_setup, which requires the channel-connection descriptor to have **both** strategy == DeviceLink **and** auth_requirement.setup == DeviceLink. Those descriptors are built solely from [channel.connection] (factory.rs:1238-1256), and never consult manifest.auth. 7766 changed Telegram's manifest: Both conditions went false, user_link_required went false, and the install result's next_step silently degraded from the device-link guidance to a plain "Activation completed; model-visible extension tools are ready." 7766 was correct — it fixed consent bug #7715 by separating bot pairing from personal device linking. It just orphaned a predicate that had been asking "does this CHANNEL connect via device link?"* when the question that matters is "does this

nearai/ironclaw issue #7856 reports: Environment IronClaw 1.3.0 deployment: 70795c16ed0cec21eb8cba16d2dcf851d25dc83d Source rechecked against main: 6f473953234f2e80d783a57876e5526c4b26013e Hosted HTTP/SSE MCP discovery Problem Hosted MCP discovery currently requires each expose tool name to be directly usable as a Reborn CapabilityId suffix. Consequently, spec-valid MCP tool names containing uppercase letters are skipped. For example, given a tools/list response containing: ping authHealth getProjectBySlug IronClaw publishes ping but skips the other two as invalid_tool_name. The current MCP specification permits uppercase ASCII letters in tool names: https://modelcontextprotocol.io/specification/2026-07-28/server/tools#tool-names Steps To Reproduce 1. Configure a hosted MCP server whose tools/list response includes both ping and authHealth, with valid object-shaped input schemas. 2. Run hosted MCP discovery. 3. Inspect the published capability catalog. 4. Observe that ping is published and authHealth is omitted. The existing concrete adapter fixture also exercises this behavior by treating UppercaseName as a shape-invalid tool while publishing the lowercase tools from the same response. In a public real-world example, https://nearbuilders.org/api/mcp expose 67 tools when tested, but only eight passed the current lowercase discovery predicate. Expected Behavior IronClaw should publish bounded, spec-valid MCP tools while retaining its lowercase internal CapabilityId requirements. Invoking the resulting local capability must send the exact server-expose name in tools/call. Actual Behavior ironclaw_mcp::discovery accepts only lowercase capability-compatible names. Unsupported names are skipped rather than normalized because normalization could create colliding capability IDs. The HTTP client later reconstructs the

nearai/ironclaw issue #7853 reports: Instance:** Railway (ironclaw-qa-testing-libsql.up.railway.app) Description The Telegram setup flow offers to link both a workspace bot and the user's personal Telegram account. The bot setup works correctly, but when the user agrees to also set up the personal account, the agent reports there is no available tool to complete that step. The agent should either be able to complete the personal account linking, or it should not offer it as an option if the capability is not available. Steps to Reproduce 1. Start Telegram setup ("lets setup telegram") 2. Agent sets up the workspace bot successfully 3. Agent then offers to help link your personal Telegram account 4. User says "yes" 5. Agent responds that it "still can't link a personal Telegram account from here because there's no available tool for that step" Expected If the agent offers to set up the personal Telegram account, it should be able to complete the flow. If the tool is not available, the agent should not offer it. Actual The agent offers personal account linking as a next step but then cannot complete it due to a missing tool. The user is led down a dead-end flow.

Why it matters

Setup copy, discovery normalization and executable linking are one product contract: advertising an unavailable path wastes both model turns and operator trust. 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-25. 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/pull/7861. Supporting records are https://github.com/nearai/ironclaw/issues/7856 and https://github.com/nearai/ironclaw/issues/7853. 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

Test setup guidance from a clean install, preserve exact MCP tool identity through discovery, and hide account-link choices until the required tool exists. 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.