mirror of
https://github.com/nearai/ironclaw.git
synced 2026-09-03 08:06:01 +08:00
9bf094fb4d
* fix(sandbox): consume the material mode on every platform
`main` has been red on `Clippy Windows (default)` and
`Clippy Windows (all-features)` since f88ef87ce:
error: unused variable: `mode`
--> crates\lanes\ironclaw_sandbox\src\sandbox_process\managed_egress.rs:1889:5
= note: `-D unused-variables` implied by `-D warnings`
`write_atomic_material_file_with_mode` took a `mode: u32` that only a
`#[cfg(unix)]` block at the call site consumed, so on Windows the parameter
was genuinely unused. This blocks cutting any release candidate: the weekly
strategy requires cutting from a commit whose required checks are green, and
no recent `main` commit qualifies.
Rather than suppress the lint, remove the reason for it. The permission apply
moves into `apply_material_mode`, with a `#[cfg(unix)]` implementation that
sets the bits and a non-unix one that is a deliberate no-op -- but still takes
`mode`. Consuming the parameter on every platform keeps a single signature,
needs no `allow`, and puts the platform difference behind a named function
instead of an inline `cfg` block.
Tested rather than exempted. The regression gate offers a `skip-regression-check`
path, but both of its forms require asserting "deterministic reproduction is
impossible", which is false here -- the Windows clippy lanes reproduce this
deterministically on every run -- so claiming it would have put an untrue
statement in the PR to buy a green tick.
`apply_material_mode_restricts_the_file_to_its_owner` asserts the mode
actually lands, not merely that the call returns Ok: these files carry proxy
credentials, so a writer that silently stopped restricting them would be a
leak rather than a style regression. The non-unix twin pins that the no-op
still accepts `mode`, which is the property that keeps the lint away.
Verified by simulating the Windows configuration on macOS (swapping which
`apply_material_mode` compiles): the crate builds clean under `-D warnings`
with no suppression anywhere. A native unix build cannot exercise this,
which is why the simulation is the local evidence and the Windows CI lanes
are the real gate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(changelog): add the v1.4.0 release entry
Covers the 81 commits since ironclaw-v1.3.0 (30 fix, 23 feat, 9 refactor,
2 perf): the durable notification inbox and actionable run gates, background
subagents with per-child delivery and healing sweeps, persistent per-user
sandbox containers behind a managed egress proxy, run-now for automations,
suggestions generated over the user's own read-only tools, Google Docs
semantic editing, and the stall/diagnostic fixes across the LLM, capability
and resource-governor paths.
The operator paragraph carries the three things a deployment actually has to
know about this release: the in-worker SSH listener is off unless
IRONCLAW_REBORN_SSH_PUBLIC_KEY is set (public-key-only as `agent` on port
2222, which must be published, and `agent` shares uid 1000 with the runtime
user so the private key is equivalent to shell access);
IRONCLAW_REBORN_WORKSPACE_ROOT is honored on both boot paths and neither it
nor IRONCLAW_REBORN_HOME may be the filesystem root; and the two new sandbox
knobs.
Upgrade note says no migration steps: installation state written by 1.2.x is
accepted and preserved, so a deployment that skipped 1.3 can come straight
here.
This lands on the release branch rather than main because the branch was cut
first. It MUST be cherry-picked back to main: the release branch freezes and
is never merged back, so an entry that lives only here disappears from the
next candidate and the live changelog silently drops this release — exactly
what happened to v1.3.0, which #7913 had to repair
(docs/internal/weekly-release-strategy.md, Candidate rules step 3).
Verified: ensure_stable_changelog_entry(".", "1.4.0") passes (it refused
before this commit), docs_publication_boundary.py and check-guidance.py OK.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
180 lines
9.2 KiB
Plaintext
180 lines
9.2 KiB
Plaintext
---
|
|
title: "Changelog"
|
|
description: "What shipped in each stable IronClaw release"
|
|
icon: clock-rotate-left
|
|
---
|
|
|
|
Each entry covers one stable release of the `ironclaw` binary; release
|
|
candidates are not listed. For full commit-level notes, see the
|
|
[GitHub releases page](https://github.com/nearai/ironclaw/releases). This site
|
|
always documents the **latest stable release** — docs for earlier releases
|
|
live in their git tags, such as
|
|
[`ironclaw-v1.0.0`](https://github.com/nearai/ironclaw/tree/ironclaw-v1.0.0/docs).
|
|
|
|
<Update label="2026-08-26" description="v1.4.0">
|
|
|
|
**Notifications, background subagents, and a sandbox that holds still.**
|
|
|
|
- **A durable notification inbox** — runs publish authoritative outcomes and
|
|
actionable gates to a per-user inbox instead of vanishing into a transcript,
|
|
and the WebUI notification center reads from it. Approvals and auth prompts
|
|
you missed are still there when you come back.
|
|
- **Background subagents** — a parent turn can spawn children that run and
|
|
deliver on their own, with per-child delivery, activation provenance, and a
|
|
derived cap on autonomous wakes. Healing sweeps recover children whose parent
|
|
went away.
|
|
- **Persistent per-user sandbox containers** on the local-Docker profile —
|
|
a user sandbox is a durable container reached over Docker Exec rather than a
|
|
fresh process per call, so container-local installs and state survive between
|
|
commands. The Railway preview profile still runs an ephemeral worker per
|
|
command and keeps only its checkpointed workspace. On both, sandbox egress is
|
|
routed through a managed per-user proxy, and extensions can declare
|
|
direct-exec credential bindings that stay behind it, so secrets are never
|
|
handed to sandboxed code.
|
|
- **Run-now for automations**, plus exact run capability facts, so a scheduled
|
|
automation can be exercised and inspected without waiting for its schedule.
|
|
- **Suggestions you can act on** — generated over your own no-approval,
|
|
read-only tools, gated on extensions you have actually connected, and
|
|
surfaced in onboarding with refresh and connect entries.
|
|
- **Google Docs semantic editing**, and conversation artifacts now carry run
|
|
timing evidence.
|
|
- **Fewer stalls and fewer surprises** — structured finalization is bounded,
|
|
OpenAI-compatible reasoning-only responses survive, provider failures and auth
|
|
diagnostics reach the model as readable context instead of opaque errors, and
|
|
libSQL write-lane starvation no longer cascades through the resource governor
|
|
as unrelated tool failures.
|
|
- **Telegram** separates workspace-bot pairing from personal device linking, and
|
|
**Slack** delivers the unlinked-user connect nudge privately with a one-click
|
|
link.
|
|
|
|
**Upgrading from 1.3.0:** no migration steps. Installation state written by 1.2.x
|
|
is accepted and preserved, so a deployment that skipped 1.3 upgrades directly.
|
|
|
|
**Operators:** the runtime image can now start an in-worker SSH listener, and it
|
|
is **off unless you set it**. Setting `IRONCLAW_REBORN_SSH_PUBLIC_KEY` to an
|
|
OpenSSH *public* key enables public-key-only login as user `agent` on container
|
|
port 2222, which must be published to be reachable. Note that `agent` shares
|
|
uid 1000 with the `ironclaw` runtime user, so an SSH session holds the full
|
|
runtime identity — treat the private key like shell access to the service.
|
|
`IRONCLAW_REBORN_WORKSPACE_ROOT` is honored on both CLI boot paths; neither it
|
|
nor `IRONCLAW_REBORN_HOME` may be set to the filesystem root. New sandbox knobs:
|
|
`IRONCLAW_REBORN_SANDBOX_PROXY_IMAGE` and
|
|
`IRONCLAW_SANDBOX_EXTRA_ALLOWED_DOMAINS`.
|
|
|
|
</Update>
|
|
|
|
<Update label="2026-08-19" description="v1.3.0">
|
|
|
|
**Your model, your automations, fewer writes.**
|
|
|
|
- **Per-user model preferences** — pick your model in Settings, the CLI, or a
|
|
chat command, and it follows you across chat and channels. Admins bound the
|
|
selectable set with a tenant-scoped model policy.
|
|
- **Automations you can trust to stay quiet** — scheduled runs carry a
|
|
validated execution contract instead of a free-form prompt, and a run with
|
|
nothing to report finishes silently rather than delivering filler.
|
|
- **Document editing** — structural edits to `.docx`, `.xlsx`, and `.pptx`,
|
|
plus PDF rendering from HTML.
|
|
- **Telegram linked devices** — pair your personal Telegram account with the
|
|
bot so the agent can read your conversations and act as you. Reads are live
|
|
and IronClaw keeps no mirror of your Telegram history; what the agent reads
|
|
in a run is retained in that conversation's transcript, like any other tool
|
|
result.
|
|
- **The complete Slack messaging vocabulary** — edit and delete messages,
|
|
add and remove reactions, open DMs, read a message, resolve a user, list
|
|
members.
|
|
- **Memory that actually recalls** — retrieval ranks by relevance instead of
|
|
demanding every word of your question appear in the saved fact, and broken
|
|
memory no longer looks like empty memory.
|
|
- **Faster, quieter runs** — opt-in parallel tool batches, Anthropic prompt
|
|
cache breakpoints, and a large reduction in per-turn database writes.
|
|
- Context-window eviction now compacts instead of dropping your task, an
|
|
unavailable tool call is repaired instead of ending the run, and secrets
|
|
bound for the model are redacted without rejecting the turn.
|
|
- Under sustained write load on libSQL, database contention no longer surfaces
|
|
as unrelated tool calls failing with a resource error.
|
|
|
|
**Upgrading from 1.2.0:** no migration steps — installation state written by
|
|
1.2.x is accepted and preserved (1.3.0-rc.1 crash-looped on it; fixed in
|
|
rc.2). **Slack re-consent:** the new Slack operations need
|
|
`reactions:read`, `reactions:write`, and `im:write`. There is no scope-upgrade
|
|
flow, so an account connected before this release answers those three tools
|
|
with a permission denial until you disconnect and reconnect Slack; the other
|
|
13 operations are unaffected. **Removed:** the standalone missions, routines,
|
|
and admin analytics placeholder pages in the WebUI, and the retired IronLoop
|
|
network settings.
|
|
|
|
</Update>
|
|
|
|
<Update label="2026-08-13" description="v1.2.0">
|
|
|
|
**Shared channels that just work.**
|
|
|
|
- **Presence-based admission** — add the bot to a Slack channel or Telegram
|
|
group and it is served, with nothing to configure: the
|
|
`slack_allowed_channels` / `telegram_allowed_channels` allowlists and the
|
|
shared-subject settings are gone.
|
|
- **Genuinely shared conversations** — a Slack thread or Telegram group/topic
|
|
is one continuous conversation every paired participant shares, and each
|
|
message still runs as the person who sent it: their identity, memory,
|
|
settings, and approval gates.
|
|
- **Slack channel context** — pinging the bot at the top level of a channel
|
|
gives the run recent channel history; pinging inside a thread gives it that
|
|
thread. Context is fetched host-side and framed as untrusted quoted
|
|
content, never as instructions.
|
|
- Unpaired users who ping the bot in a shared conversation get a connect
|
|
notice as a reply on their own message instead of silence.
|
|
- Every parked approval or auth gate is announced individually, in the live
|
|
conversation and the background automation lane alike.
|
|
- The runtime container image now ships `curl`, so orchestrator HTTP
|
|
healthchecks pass; Windows first-start filesystem publication and release
|
|
smoke runs are fixed.
|
|
|
|
**Upgrading from 1.1.0:** the shared-channel allowlist and subject settings
|
|
(`slack_allowed_channels`, `telegram_allowed_channels`,
|
|
`slack_shared_subject_user_id`, `slack_subject_routes`) are removed —
|
|
admission is presence-based. Previously stored shared-channel notification
|
|
preferences fail closed; DM delivery targets are unchanged. A gate prompt
|
|
delivered but not yet acknowledged when this version deploys re-announces
|
|
once.
|
|
|
|
</Update>
|
|
|
|
<Update label="2026-08-06" description="v1.1.0">
|
|
|
|
**Extension reach and legible failures.**
|
|
|
|
- **Custom MCP servers** — register a hosted MCP server from the WebUI and use
|
|
its tools like any other extension, with bounded tool discovery and auth
|
|
resolved during registration.
|
|
- **IronHub install flow** — install extensions from an IronHub deep link,
|
|
including private packages.
|
|
- **Durable file attachments** that cross channels.
|
|
- **Slack `/ironclaw` slash commands.**
|
|
- A broad pass on making failures legible: the model is told what to do next
|
|
instead of hitting an opaque stop, and users get localized, actionable
|
|
errors instead of silent dead ends.
|
|
|
|
**Upgrading from 1.0.0:** no migration steps. Extension lifecycle state moved
|
|
to a normalized on-disk shape; rows written by 1.0.0 keep deserializing.
|
|
**Removed:** the `/webhooks/slack/events` compatibility alias.
|
|
|
|
[Full release notes](https://github.com/nearai/ironclaw/releases/tag/ironclaw-v1.1.0)
|
|
|
|
</Update>
|
|
|
|
<Update label="2026-07-27" description="v1.0.0">
|
|
|
|
**First stable release of the rearchitected IronClaw** — a ground-up rebuild
|
|
of the agent runtime, storage, extension host, and web UI, shipping as the
|
|
`ironclaw` binary on seven platform targets.
|
|
|
|
**Not an in-place upgrade from 0.29.x:** there is no migration for v1 config,
|
|
databases, settings, or secrets. Treat it as a fresh install — point
|
|
`IRONCLAW_REBORN_HOME` at a new directory, run `ironclaw onboard`, and
|
|
reconnect your providers and channels.
|
|
|
|
[Full release notes](https://github.com/nearai/ironclaw/releases/tag/ironclaw-v1.0.0)
|
|
|
|
</Update>
|