What's new
in MIRA.

New here? Install or update MIRA

1. v0.359.2 Current build

   Web-push crypto, replaced in-house

   • Removed a vulnerable crypto dependency. MIRA’s web-push stack previously relied on a third-party library that pulled in a yanked/vulnerable crypto cluster — including the unfixed RSA “Marvin attack” advisory. It’s been replaced with an in-house implementation: VAPID (RFC 8292) JWTs signed with P-256 ECDSA, and RFC 8291 payload encryption via HKDF/SHA-2. Push notifications behave identically and existing subscriptions keep working — the VAPID key file is unchanged.
   • Net effect across v0.359.1–v0.359.2: MIRA’s Rust dependency audit dropped from 28 flagged advisories to 3 — and those 3 sit behind an optional, off-by-default ML feature that stock builds don’t ship.

   A security-hardening patch — no config, schema, or on-disk changes. Safe to upgrade in place; clients need no update.

2. v0.359.1

   Config-path fix and dependency security

   • The MIRA_CONFIG environment variable is now honoured everywhere — the main CLI, upgrade, rollback, the Windows service, and backups — with a consistent precedence: --config flag > MIRA_CONFIG > default path. Previously the main CLI ignored it and dropped into the first-run wizard. Reported by the community (issue #14) and fixed quickly.
   • Security: dependency updates clearing a batch of advisories across the TLS stack (rustls), the QUIC layer (quinn), the WebAssembly runtime (wasmtime), HTML sanitisation (ammonia) and archive handling (zip).

   A bug-fix and security-maintenance patch — no config, schema, or on-disk changes. Safe to upgrade in place; clients need no update.

3. v0.359.0

   Skill authoring — admin controls & quick wins

   • A per-role authoring cap. The admin Capability editor gains a Max authoring tier control: cap how far a given role may go when authoring skills — guidance-only (0), or also allowed to re-expose a built-in tool (1).
   • Opt-in “save this as a skill.” When MIRA notices you asking for the same kind of task more than once, it can offer to save it as a reusable skill. Off by default, one offer per pattern, always dismissable (agent.skill_authoring.propose_on_repetition).
   • Cleaner package uninstalls. Removing a package that installed an MCP server now removes only that package’s server — never another admin’s.

   Additive — no config migration and no breaking changes. Safe to upgrade in place; clients need no update.

4. v0.358.0

   Skill self-authoring, tier 1 — safely reuse built-in tools

   • MIRA can now author a skill that re-exposes an existing built-in tool, not just a guidance-only (instructions-only) skill. The rule that keeps this safe: a skill’s effective power is always the intersection of what the skill asks for and the caller’s own permissions — so a reuse skill still only runs that tool for someone whose role already allows it. Authoring a skill can never hand anyone a capability they didn’t already have.
   • Skills now carry an authoring tier that reflects what they actually do: guidance-only → reuse a built-in tool → side-effects → executable. A new “New Skill” form in the web UI lets you author one directly.
   • CLI: mira skill init --builtin <tool> scaffolds a reuse skill, and mira skill validate now reports the tier.

   An additive feature — no config migration, no breaking changes, and no permission escalation by design. Safe to upgrade in place.

5. v0.357.1

   Security maintenance — MCP server env values encrypted at rest

   • MCP server environment values are now encrypted at rest, the same protection the MCP bearer token already had. Existing values are migrated automatically on first upgrade — no user action needed.

   A security-hardening patch — no config or behaviour changes. Safe to upgrade in place; clients need no update.

6. v0.357.0

   Bearer-token auth for HTTP MCP servers

   • Connect to protected HTTP MCP servers. A Streamable-HTTP MCP server can now carry a per-server bearer token, which MIRA’s MCP client sends as an Authorization: Bearer … header. You supply the token from the MCP admin page (transport http → URL + bearer token); it’s stored encrypted at rest and never returned by the API. A new additive config key mcp.servers[].auth_token backs it. This is for authenticated HTTP endpoints — stdio MCP servers are unaffected.
   • Contributed by the community. With thanks to @afalter (#13) — their second merged contribution, after the OpenCode Go provider in v0.352.0.

   An additive feature — additive config, no migration, and no breaking changes. Safe to upgrade in place; clients need no update.

7. v0.356.2

   Package-install fixes

   • Two small patches to the package-install path on top of v0.356.0. v0.356.2 fixes a reinstall failure — reinstalling an MCP-server package could error with a database UNIQUE conflict; installs now update in place, so reinstall behaves correctly. v0.356.1 fixes installing from the in-app Browse list and by URL — channel-provider (cpp_provider) packages couldn’t be installed that way, and the Plugins “Install” button was wrongly disabled for any URL-sourced package (which had also blocked MCP-server installs from Browse).

   Maintenance patches — no config or schema changes, no breaking changes. Safe to upgrade in place. For reliable Browse-based package install, run 0.356.2 or later.

   How packages & trust work
8. v0.356.0

   Official packages, trusted out of the box

   • First-party packages just work — safely. MIRA now bundles and auto-pins the Vexillon publisher’s signing key and ships the first-party package source enabled, so a stock instance can discover and install official packages that show as Verified with zero operator setup. The catalog is MIRA’s first-party package index at github.com/Vexillon-ai/mira-packages — a signed index instances fetch and verify against the pinned key.
   • The security posture is unchanged. Trusting the first-party source by default doesn’t bypass anything: every install still runs MIRA’s per-artifact trust check — signature and hash — at install time. Community publishers remain Untrusted (trust-on-first-use) until an admin explicitly pins their key, and the default source is admin-disableable.

   A trust/UX convenience that completes the v0.355.0 package system — no config migration and no breaking changes. Safe to upgrade in place; clients need no update.

   How packages & trust work
9. v0.355.1

   Settings → Skills panel

   • A small admin convenience. A new Settings → Skills tab lets an admin toggle the skill self-authoring switches from the web UI instead of hand-editing the config file. Same controls, now in the UI — no behaviour change.

   A minor UI addition — no config migration and no breaking changes. Safe to upgrade in place; clients need no update.

10. v0.355.0

    Package distribution — install skills & plugins from signed sources

    • Install skills and plugins from a signed source. You can install from a URL, or add admin-managed distribution sources: MIRA fetches a source’s signed catalog (index.json), verifies it against the source’s pinned key, caches it, and merges it into a Browse-and-install list — with a separate surface for packages that have an update available. A CLI signing tool (mira skill index-sign) lets you publish your own signed catalog.
    • Off by default — and it does not phone home. The first-party source ships disabled, with no pinned key, so a stock instance contacts no new host until an admin explicitly enables a source and pins its key. Catalog fetches are admin-only and SSRF-guarded.

    An additive feature — no config migration and no breaking changes. Safe to upgrade in place; clients need no update.

    How packages & trust work
11. v0.354.0

    Skill self-authoring — MIRA can save its own know-how

    • MIRA can propose a reusable skill after a non-trivial task. When it works something out, it can offer to save that know-how as a Tier-0 guidance skill — instructions only — so it’s ready next time. By construction a self-authored skill grants no new capability: no new tools, and no network, file, or secret access. It can only write down how to use what MIRA already has.
    • Private, visible, and governed. Proposals are private to you by default and auto-approved but always visible, with one-tap disable; they’re governed by role-based access control and signed per instance (“Signed by this MIRA”). An admin can promote a user’s skill to a global one when it’s broadly useful.

    An additive feature — on by default but fully visible and disable-per-skill, with no new capabilities granted, no config migration, and no breaking changes. Safe to upgrade in place.

12. v0.353.0

    Connect any OpenAI-compatible model from the setup wizard

    • A “Custom (OpenAI-compatible)” option in mira setup. The setup wizard now offers a custom endpoint alongside the named providers (OpenAI, OpenRouter, OpenCode Go, Anthropic, Gemini, DeepSeek, Groq, xAI, Ollama, LM Studio). Point it at any OpenAI-compatible endpoint — your own base URL, an auth style (Bearer / none / Azure) and an API key — and it tests the endpoint, picks a model, and wires it up for you. No hand-editing the config file. That covers self-hosted gateways, vLLM / LiteLLM, a proxy, or a remote LM Studio / Ollama behind an auth proxy. (It maps to the existing providers.openai_compat block — you just no longer need to touch it by hand.)
    • Scriptable for headless installs. The same path runs unattended via the environment variables MIRA_SETUP_PROVIDER=openai_compat plus MIRA_SETUP_BASE_URL / MIRA_SETUP_API_KEY / MIRA_SETUP_AUTH_STYLE.
    • No breaking changes and no new dependencies.

    A setup/onboarding enhancement — no config, schema, or API changes, and existing setups are unaffected. Safe to upgrade in place; clients need no update.

13. v0.352.0

    OpenCode Go provider — and MIRA’s first community contribution

    • Another provider option: OpenCode Go. MIRA adds support for OpenCode Go, an OpenAI-compatible LLM provider. Configure it with a new providers.opencode config block (default base URL https://opencode.ai/zen/go/v1) and select it as your primary_provider. It sits alongside the existing providers — one more option, not a change to any of them.
    • MIRA’s first community-contributed provider. This is the first LLM provider contributed by someone outside the core project — by @afalter (PR #10) — and the NOTICE file now credits “and MIRA contributors.” MIRA is open to community contributions, and this is the first one in.
    • Minor cleanup: the empty-completion retry log wording is now consistent. No breaking changes.

    A minor feature release — no config migration required and existing setups are unaffected. Safe to upgrade in place; clients need no update. With thanks to <code>@afalter</code> for the first community-contributed provider.

14. v0.351.6

    Calendar & timezone accuracy

    • A run of correctness fixes (v0.351.4–v0.351.6) so the assistant gets your calendar dates, times and ranges right, in your own timezone. The calendar tool now hands the model ready-to-read local date/time strings — per event, and the queried window’s start and end — and the model quotes them verbatim instead of computing weekday maths itself. That fixes smaller models occasionally naming the wrong weekday, time or date range (for example a mis-stated “Monday 12 to Sunday 19”).
    • Calendar and Automations render in your timezone. Event, schedule and briefing times now use your profile timezone instead of the browser’s, and the month grid buckets each event — and the automation/briefing markers — by its date in that timezone, so an event can no longer show the right time on the wrong day.
    • API: an optional timezone field (your IANA profile zone, e.g. Pacific/Auckland) is now included on the /api/auth/me, login and guest-mint responses. It’s additive and backward-compatible — omitted when unset, so existing clients are unaffected.

    Correctness fixes with no config or migration changes. Safe to upgrade in place; the one API addition is an optional field, so clients need no update.

15. v0.351.3

    UI polish — cleaner counters, mobile-friendly times

    • Three small quality-of-life fixes to the web UI: the token-usage counter now hides a ↑ (context) or ↓ (output) segment when it’s zero, so a fresh turn no longer shows a stray 0↑; calendar event, schedule and briefing times no longer clip to “12:0” on narrow/mobile widths; and the Enter / Shift+Enter / Esc keyboard hints are now hidden on touch devices where they don’t apply. No backend changes.

    A cosmetic/UX patch — no features, API, config, or migration changes. Safe to upgrade in place; clients need no update.

16. v0.351.2

    Better compatibility with strict OpenAI-compatible gateways

    • Cleaner outgoing requests to OpenAI-compatible providers. An internal prompt_cache flag was being serialised onto outbound requests, where it was never meant to travel — strict gateways that reject unknown fields could choke on it. It no longer appears in the request body (input handling is unchanged), and a regression test pins the behaviour so it can’t come back.
    • Minor web UI dependency bump (source-map-js, build-time only). No backend logic changes.

    A maintenance/compatibility patch — no features, API, config, or migration changes. Safe to upgrade in place; clients need no update.

17. v0.351.1

    Security maintenance — web UI dependencies

    • Updated the bundled web UI dependencies to clear all outstanding advisories — npm audit now reports zero vulnerabilities. No features, no app logic, and no API or config changes; the backend is unchanged.

    A security-maintenance patch on top of v0.351.0 — no features, API, config, or migration changes. Safe to upgrade in place; clients need no update.

18. v0.351.0

    No more blank replies on flaky gateways

    • Automatic retry on empty AI responses. Some providers occasionally return a “successful” but completely blank completion — no text and no tool call — most often on load-balancing gateways (like OpenRouter), where one upstream returns empty while the others work fine. That used to surface as a mysterious empty reply in your chat. MIRA now detects the blank response and automatically re-issues the request (up to 2 retries by default); on a gateway, the retry can land on a different, healthy upstream. If it’s still empty after retrying, the turn fails cleanly and is counted as a provider error — so health and failover routing can react — instead of showing you nothing. A genuine tool-call turn is never mistaken for empty, and this covers every AI call: chat, auto-titling, and the memory/wiki extractors. On by default.
    • Tunable if you want it. A new agent.empty_response_retry config block lets operators turn it off (enabled, default true) or change the retry count (max_retries, default 2). The defaults are sensible — most people need do nothing.

    A minor feature release — on by default, no breaking changes, no migration. Safe to upgrade in place; clients need no update.

19. v0.350.5

    Remote MCP over HTTPS, and security maintenance

    • Remote MCP servers over HTTPS now work. Connecting to a remote Streamable-HTTP MCP server over https:// previously failed before the handshake (“invalid URL, scheme is not http”), because the MCP client’s HTTP stack had no TLS backend. It now has one and connects correctly. (OAuth for protected/authenticated MCP servers is a separate feature that isn’t implemented yet — this covers the HTTPS transport only.)
    • Security dependency updates. A batch of security-sensitive dependencies was refreshed — TLS, HTML sanitisation, the WASM sandbox runtime, PDF parsing, serialisation, and others — clearing the outstanding advisories. One low-relevance advisory has no upstream fix yet, but it isn’t reachable in MIRA (the affected algorithm isn’t used — Web Push uses ECDSA/ES256), so there’s no exposure.
    • Building from source with --locked is fixed. The published manifest was missing a dependency line, so cargo build --locked from the public repo couldn’t resolve. The manifest now matches the lockfile, with a consistency check added to the release process so it can’t recur. (Relevant only if you build from source — not for the prebuilt binaries.)

    A bug-fix and security-maintenance patch — no features, API, config, or migration changes. Safe to upgrade in place; clients need no update. With thanks to community contributor @afalter, who reported the HTTPS-MCP and source-build issues.

20. v0.350.4

    Bug fixes — OpenRouter, Discord & service control

    • OpenRouter chats no longer get stuck. Tool-using conversations could hit a response-parsing bug in the usage/token-count block that failed the turn — and its automatic retry — with no useful diagnostics, leaving the chat unusable. The parser now tolerates the varying shapes that block can take, so a malformed one can’t break the whole response, and when parsing does fail the raw body is logged (bounded) so the cause is visible. This affected anyone using OpenRouter with tools, and is the most user-visible fix in this release.
    • Discord starts cleanly. Enabling the Discord channel could send the process into a restart loop from a TLS crypto-provider initialisation conflict. It now starts without looping.
    • Service control fixed for system installs. start / stop / restart / status now act on the correct service for --system (system-scope) installs, instead of only targeting the per-user service.
    • Steadier agent runs. A child process that closes its input early no longer spuriously fails the run.

    A bug-fix patch — no features, API, config, or migration changes. Safe to upgrade in place; clients need no update. With thanks to community contributor @lafkpages, who reported the OpenRouter, Discord, and service-control issues.

21. v0.350.1

    Security fix — per-user notification scoping

    • The real-time notification stream is now scoped per user. The server-sent-events endpoint GET /api/notifications/stream was subscribing to the shared notification bus without filtering by the authenticated caller — so on a multi-user install, every connected client could receive every user’s notifications, and a notification carries the actual message text (proactive follow-ups, companion check-ins, inbound-message previews). The stream now filters strictly per user: a user-addressed notification reaches only that user, while global system/health notices reach regular users but not ephemeral guest sessions. The web-push path was already per-user and was unaffected.
    • Who’s affected. This was latent on a single-user self-host, but a genuine cross-user information disclosure the moment a second account connects — so it matters for any multi-user / RBAC / SSO deployment. Anyone running MIRA for more than one account should upgrade. Single-user installs are unchanged in behaviour (you still receive all of your own notifications) and need no action, though upgrading is safe and recommended. Clients need no update.

    A security-only patch — no features, API changes, config changes, or migration. Safe to upgrade in place. Details in the security advisory.

    Security advisory
22. v0.350.0

    Restricted Mode — safely expose MIRA

    • Fail-closed by design. Turn on a restriction profile and every side-effecting capability is denied unless it’s on an explicit allow-list. The check sits at each chokepoint — the tool registry, the skill→builtin path, outbound HTTP, and the proactive/companion message senders — so there’s no back door around it, the model can’t talk its way past it, and no user, UI, API, or prompt path can widen it at runtime. It’s off by default: existing installs behave exactly as before, and upgrading is safe in place (no config or on-disk migration).
    • A built-in “hardened” profile. Permits chat and reasoning, per-user memory, and the wiki — and denies shell, code execution, filesystem writes, real outbound channel messages, care-network escalations, home-automation actuation, and arbitrary web fetch. Anything not explicitly allowed is denied, so a newly-added tool is denied by default rather than newly exposed.
    • Resource & cost caps. Per-user message rate, a per-turn token cap, a context budget, global concurrency, and a global daily token ceiling. A tripped cap degrades gracefully with a brief, friendly in-chat reply instead of a raw error or unbounded spend — ideal for bounding cost and load on a public instance.
    • Ephemeral guest sessions. Anonymous “try it” access via a new public endpoint (POST /api/auth/guest). Each guest is a throwaway, sandboxed account with its own seeded, isolated memory and wiki, wiped on a TTL, on a periodic global reset, and unconditionally on restart — guests never persist. Fail-closed: a guest is only ever minted when a restriction profile is also active.
    • Admin visibility. A read-only Restricted Mode panel in admin Settings shows the active profile, what’s denied, the caps, and guest status at a glance.

    Off by default and safe to upgrade in place — existing installs are unchanged. Turn it on only when you mean to expose MIRA (a public “try it” demo, a kiosk, a shared guest instance) or to shrink the blast radius of a prompt-injection attack. It’s defence-in-depth, not a replacement for a VPN when reaching your own instance.

    Guide: Safely expose MIRA (Restricted Mode)
23. v0.346.1

    Reliable self-upgrades, and a Settings tidy-up

    • The in-app self-upgrade now shows real progress. It always worked, but a fixed timeout expired before a typical upgrade finished, so it looked like it had failed. The banner and Settings now show the real phases — downloading → verifying → installing → restarting — and only report a problem on an actual error or a genuine stall.
    • No racing upgrades. Starting a second upgrade while one is already running now safely re-attaches to the in-progress job instead of launching a competing swap.
    • Windows fixes. Old-binary cleanup now runs when MIRA is installed as a Windows service, so upgrades no longer leave large leftover files behind, and the Upgrade and Rollback buttons now appear correctly in Settings on Windows service installs.
    • Settings tidy-up. Finishing the “My Preferences” move from last release, the per-user controls still duplicated in admin Settings are now consolidated: mobile pairing, browser push, and their test buttons live in My Preferences → Notifications & devices; the daily-briefing toggle stays on the Presence page; and the Settings “Appearance” section is now Terminal (TUI) — TUI theme only, since the web theme lives in My Preferences. Nothing per-user is trapped behind admin-only Settings anymore.

    Safe to upgrade in place — no breaking changes. When you run the in-app upgrade, just let it finish: a repeat click only re-attaches to the running job, and the page reloads itself onto the new version automatically.

    Guide: Updating & rolling back
24. v0.345.1

    A My Preferences page for every user

    • Every user gets a My Preferences page. There’s now a per-user My Preferences page at /preferences, with its own sidebar link, open to everyone — not just admins. It fixes a real gap: mobile pairing and browser push notifications are per-user, but they used to live on the admin-only Settings page, so a non-admin couldn’t pair their phone at all. Now they can.
    • Your per-user settings, in one place. My Preferences gathers the settings that are genuinely yours: Notifications & devices — pair the mobile app by QR and manage browser push; Appearance — pick your web theme; and Voice replies — your per-channel voice-reply policy and voice override, moved here from the Profile dialog. The Profile dialog is now just your account details — name, contact, password, avatar — while global and server configuration stays admin-only.
    • Steadier sessions across your devices. Refresh-token handling was hardened so a harmless refresh race on one device — a lost response, or an app the OS killed — no longer revokes every session across all your devices. Each device now stands on its own, and a just-rotated token gets a short grace window to retry cleanly.

    Safe to upgrade in place — a small, automatic, backward-compatible database migration runs on first boot, with no manual steps. Existing sessions adopt the new per-device behavior on their next refresh (or log in once more per device to switch immediately).

    Guide: Pair the mobile app
25. v0.344.0

    Fail-closed messaging webhooks

    • Breaking change — set a webhook secret before upgrading. Inbound Telegram and WhatsApp webhooks are now fail-closed: an inbound webhook for an account with no per-account secret configured is rejected instead of accepted unverified, closing a hole where anyone who learned your (non-secret) account id could POST forged inbound messages. Migrate each account one of two ways — recommended: set the account’s secret from the Channels page in the web UI (Telegram secret_token, included in your setWebhook call, or WhatsApp app_secret); or, only if you can’t register a secret and accept the risk, explicitly opt in with channels.telegram.allow_insecure_webhook = true / channels.whatsapp.allow_insecure_webhook = true (default false). Telegram polling mode is unaffected — this is webhook delivery only.
    • Account recovery & stronger passwords. A new mira reset-admin-password [--user <name>] gets you back into a locked-out admin account: run it locally and it prompts for a new password, writes it through the auth service, and revokes existing sessions (it needs filesystem access to the auth database, so it’s an operator-on-the-host recovery path). The minimum admin-password length is raised from 8 to 12, with a nudge toward a passphrase, on both first-run setup and the reset flow.
    • Tighter governance. Member-device anti-spoof is now enforced at a single shared, fail-closed checkpoint, so every actuation path — including direct app-tool calls — verifies a device really belongs to the member it claims. Guardian approvals are widened so a ward’s designated guardian, not just the operator, can approve an action, and member-device approvals now surface in the web UI instead of silently failing. App iframes now carry a runtime-enforced Content-Security-Policy (connect-src 'none'), so an embedded app can’t make network calls even if its markup tries.
    • Docs. The video_generate tool is now documented correctly as multi-backend (local ComfyUI / WAN2GP), not tied to a single provider.

    No data migration is required — upgrade is safe in place. The only action is the per-account webhook step above: if you use Telegram or WhatsApp inbound webhooks, register the account’s secret (or opt into unverified inbound) before or right after upgrading, or those inbound messages will be rejected.

    Reference: CLI (mira reset-admin-password)
26. v0.340.1

    Purpose-built health probes: /livez and /readyz

    • Breaking change — monitors pointed at /health should move. MIRA’s single overloaded /health endpoint is now split into two purpose-built probes. Point external uptime monitors and container HEALTHCHECKs at /livez (or /readyz for readiness). MIRA’s own supervisor auto-migrates a configured …/health probe URL to …/livez, and the bundled Docker image already uses /livez — so most setups need no change, but hand-rolled monitors on /health should be updated.
    • /livez — liveness. “Is the process up?” Answers instantly, with no provider, database, or subsystem calls — so it stays responsive even when a dependency is momentarily wedged.
    • /readyz — readiness. “Can it actually serve?” Returns 200 or 503 on provider reachability, and the verdict is cached so a fleet of load-balancer probes can never hammer your provider or block — at most one real check per window. Tunable via server.readiness_cache_ttl_secs (default 30s; 0 disables caching).
    • /health is now the in-app System Health page — the admin view in the web UI — rather than a machine endpoint.
    • Automations gain reach and control. An admin can create a schedule on behalf of another user (the owner’s quota applies; the admin action is audited separately), the editor adds per-run iteration and time-budget controls, and sub-daily schedules now default to a fresh conversation per run. Built-in tools invoked through a skill now receive the caller’s user, conversation, channel, and timezone, so wiki, memory, and calendar work through skills exactly as they do directly.
    • Housekeeping. Refreshed dependencies clear the outstanding security advisories (React Router 7, PostCSS, js-yaml, and others), and auto-titles no longer pick up a model’s reasoning scaffolding — a conversation is named from its real title, not a line like “1. Analyze User Input:”.

    Upgrading is safe in place. If you only wire one probe, wire /livez — a liveness check that can block on a dependency is a self-inflicted outage, and /livez never does dependency I/O. Both probes are unauthenticated and return no instance detail.

    Guide: Health checks & monitoring
27. v0.338.0

    A care role for adults who need support

    • A care role that fits an adult who needs support. The Presence care network used to offer only Just me, A child, or An older adult — so a grown-up who wants someone actively looking out for them (recovery, a chronic condition, living alone, a hard stretch) had to miscast themselves as “an older adult.” There’s now An adult who needs support: monitored like the child and older-adult roles — a care contact is alerted on distress or a worrying silence, and can see an aggregate wellbeing view (engagement signals over time, recent distress flags, never message content).
    • On the person’s own terms. The wellbeing view is gated by a hard floor — the person must be in a monitored care role and have consented after being told — and the role is framed as a peer: supportive tone, no age framing. The care-role selector is now Just me / An adult who needs support / A child / An older adult.
    • Clearer update checks. The built-in update check now explains why a release-source check failed instead of failing silently, and shows the configured source (credential-stripped) in Settings. It only compares versions — it never downloads or installs.

    The arrangement is always disclosed to the watched person, consent-gated, shares only a minimal signal (never transcripts), and is a heads-up — not emergency dispatch. Even a “Just me” user’s safety contact is still alerted in a genuine emergency; the role only changes tone and the ongoing wellbeing view, not whether a contact is reached when it matters.

    Guide: Proactive check-ins & safety contacts
28. v0.335.0

    Care network, easier to set up

    • Pick a safety contact by name. Choosing a Presence safety contact — or anyone in a people-picker — no longer means pasting a raw user id: just start typing a person’s name and MIRA searches over username and display name. It searches active users only and returns just the name and id, never anyone’s email, role, or profile details.
    • Name more than one contact. On every path you can now name several — both parents of a child, or two adult children looking after an older parent — and a distress or missed-check-in alert reaches all of them.
    • The care network is for any adult. It isn’t only for children and older adults: any adult can name their own safety contact for emergency escalation. The care-role setting only changes tone and the ongoing wellbeing view — never whether a contact is actually reached.

    The arrangement is always disclosed to the watched person, consent-gated, and shares a minimal signal — never message content.

    Guide: Proactive check-ins & safety contacts
29. v0.334.0

    Research that reaches the wiki

    • Long research runs aren’t cut short. A per-action time limit is now configurable (automations.max_action_secs, default 300s), and a research prompt can raise its own ceiling — so a genuine multi-cycle job (search → fetch → write, ~15 min) runs to completion instead of being killed mid-way. Automation runs are also dispatched off the main loop, so one slow task can’t stall other scheduled actions or the next tick.
    • Enough rounds to actually write. A research prompt’s iteration budget is honoured directly, so it gets the search → fetch → write rounds it needs to record what it found — too small a budget was the classic “searches all day but never saves.” You can always edit anything the agent wrote to your wiki, and a write that keeps getting blocked stops hammering the review queue after a few tries.
    • A rich wiki UI. Pages now render as markdown with a View / Edit toggle — headings, tables, task lists, syntax-highlighted code blocks, blockquotes — and editing shows a live preview. Pages can embed images: click Insert image or paste / drag-and-drop into the editor. Images live in the wiki’s own assets/ folder, content-addressed so they travel with git sync and tarball export (PNG/JPEG/WebP/GIF, up to 10 MB).
    • Wiki controls in one place. A new Settings → Wiki tab gathers the review-gate controls — extraction mode, minimum confidence, max updates per turn, an auto-apply threshold, and the model’s own write mode.

    Wiki extractions go through a review gate you control: confident ones can auto-apply while uncertain ones queue for your approval. Nothing is written silently, and you can correct or delete anything MIRA wrote.

    Guide: Run long research automations
30. v0.333.0

    Family governance

    • More than one guardian per ward. A ward — a child or an older adult you look after — can now have several guardians, both parents for example. A distress or gone-silent heads-up reaches all of them and counts as delivered if it reaches any one, so a single unreachable guardian can never silence the alert.
    • A quiet wellbeing view. A guardian sees an aggregate wellbeing view of each ward they look after — engagement signals over a trailing window and any recent distress flags, never the person’s messages. It’s gated by a hard floor: the person must be a monitored care role and have consented, and an ordinary adult’s data is never visible to a contact, even to an admin.
    • Member-scoped protective actions. In Active mode the Guardian can propose a bounded, reversible action on a family member’s device — pausing a ward’s internet plug through a Home Assistant integration, say — with approval routed to that member’s guardian(s), and only ever after a human approves.
    • Delegated approvers. An owner can let a trusted family adult approve or decline the Guardian’s household fixes — “your Signal bridge is stuck, approve the restart?” — without handing them full admin.
    • Container-backed apps. An app package can now declare a managed service container — a long-running backend MIRA supervises for you: started detached, restarted on failure, reaped on uninstall, and reconciled on startup, using whichever engine you have (Docker or Podman). It makes a homelab stack like Wazuh sustainable for a family, because MIRA babysits it and the Guardian watches its health. Ports stay loopback-only unless you explicitly mark them public.

    The safety arrangement is always disclosed to the watched person — never covert — consent-gated, and shares only a one-line signal summary, never transcripts. It’s a heads-up to a trusted human, not emergency dispatch.

31. v0.332.0

    Time-aware memory recall

    • MIRA now knows what “now” is. Every turn carries the current date and time resolved to your timezone (UTC as a fallback), and each recalled fact is tagged with when it was recorded — “recorded 3 weeks ago” — so the model can tell a fresh fact from a stale one instead of surfacing a month-old plan as if it were still current.
    • Old facts are read in context. Durable facts — your name, home, relationships, ongoing preferences — hold regardless of age, while time-bound ones like a trip or an appointment are treated as possibly already past, so a “tomorrow” recorded weeks ago is understood as likely done, and MIRA asks rather than assumes when it matters.
    • Nothing is silently rewritten. Memories aren’t auto-expired or edited — a past appointment stays stored, just labelled with its age — and MIRA reasons from those labels, so a weaker local model may occasionally still miss the reconciliation.
32. v0.331.0

    Security & reliability hardening

    • Every setting does what it says. The whole configuration surface was reviewed declared-vs-wired, so no config key silently does nothing: dead no-op keys were removed and several settings that were previously inert are now honored — including video defaults, session max-turns, calendar scopes, and TUI display options. Old configs still load, with removed keys dropped automatically by an upgrade-safe migration, and the bundled settings reference is now generated from the schema so docs and config can’t drift.
    • “Off the record” is auditable and honored. Going off the record is now written to the tamper-evident audit log as a consent-skip, and an off-the-record turn no longer stores a companion engagement label — while genuine distress still escalates.
    • Safety alerts reach a real person. Care-net escalations now deliver over the contact’s own messaging channel — Signal, Telegram, email, whichever they last used — with the web thread kept as a durable record. The “no one was alerted” alarm fires only if both paths fail.
    • Streaming TTS and log rotation now work as configured. The chat text-to-speech streaming toggle actually gates streaming vs. full-buffer playback, and size-based log rotation is honored with the live log stream following the rotated file.
    • Guardian gains an opt-in autonomy on-ramp. When the Guardian can’t reach you, it can take a narrow, allowlisted action — a per-action allowlist (default: re-run an audit only), an explicit confirm in Settings → Guardian → Autonomous action, and a hard code ceiling that configuration cannot widen. Observe-only and off by default.
33. v0.321.3

    Security & reliability hardening

    • Stronger sign-in. Single sign-on now requires a verified email before it will link or create an account, closing an account-takeover path (a per-provider opt-in covers providers you deliberately trust, default off). “Sign out everywhere” now takes effect immediately for every active session and token, instead of waiting for short-lived tokens to expire.
    • Permissions enforced everywhere. Tool endpoints and scheduled automations now honor your role’s permissions, so a restricted user can’t reach a tool their role forbids; several admin-only operations are properly gated, with per-route upload size limits.
    • Safer outbound requests and email. User- and admin-supplied URLs — CalDAV calendar sync, health webhooks, provider fetches — are checked against server-side request forgery: loopback and cloud-metadata addresses are refused while your self-hosted LAN services stay reachable. A new opt-in per-account option only trusts an allowlisted email sender whose mail actually passed SPF/DKIM/DMARC, so a forged “From:” can’t impersonate one.
    • Quieter about secrets. The first-run admin password prints to the console only, never the log file, and a member’s “don’t record this” request is honored server-side across both memory and the wiki.
    • Companion safety. Distress de-duplication is severity-aware, so an urgent alert is never masked by a milder one and very short messages like “help” aren’t dropped. Check-in tracking is more accurate — inbound on any channel resets the missed counter, and a web check-in counts only once delivery is confirmed. Safety-path failures now surface on the health page with a toast instead of a silent log entry.
    • Reliability. Releases are gated on the full test suite, config saves are atomic so an interrupted save can’t truncate your live config, and interval schedules no longer drift.
34. v0.318.7

    Leaner prompts, steadier local models

    • Up to ~83% fewer prompt tokens per turn. With prompt caching and adaptive tool selection on, MIRA now sends a small, stable core toolset plus on-demand tool search instead of every tool’s full schema every turn — a measured chat turn dropped from ~24K to ~4K prompt tokens. Cheaper, faster, and far easier for a small local model to handle.
    • Context budgeted to what the model can actually use. MIRA sizes the working window to a model’s reliable range instead of an inflated advertised maximum, keeps injected memory and wiki context to a modest share of it, and now counts tool schemas in its token estimate. A startup sanity check for LM Studio and Ollama warns when your configured context length doesn’t match the model’s actually-loaded window — a common cause of silent truncation.
    • Steadier thinking. The degeneracy guard now also watches the reasoning stream, so a model stuck repeating itself while “thinking” is caught and the turn fails early instead of running to the token cap. Large tool results are clamped to the effective window mid-conversation so they can’t overflow a small model.
    • Fewer sharp edges. System content is coalesced into one leading block, so strict local chat templates no longer return HTTP 400 from stacked system messages. Config saves are atomic — an interrupted or racing save can’t truncate your live config. And a provider key you set in the UI wins over a stale .env value, with a warning when .env would shadow it.
35. v0.318.0

    Sturdier apps and more reliable local models

    • Apps talk to HTTP services more reliably. App HTTP-tool base URLs work with or without a trailing slash — no more doubled slash sending an app pointed at, say, a Home Assistant instance into spurious 404s. Large API responses are trimmed to a small model-facing size before the model sees them, so a big reply can’t blow up the context, and an app can now declaratively project a few fields (with a row limit) to collapse a large JSON reply into a compact list — no code execution involved.
    • Edit app settings in the UI. The in-app config panel for apps (from v0.317.0, folded into this build) lets you change an app’s settings right in the interface.
    • Local models kept in their reliable zone. MIRA now budgets local providers to a small, dependable effective context window (default 8192 tokens) instead of trusting an advertised size that quantized local models don’t genuinely attend to — keeping prompts reliable and enabling compaction. An explicit context length still wins.
    • Degenerate-output guard, on by default. If a model gets stuck emitting pathologically repetitive text, MIRA cuts it off early, discards the bad turn, and counts it as a provider error so failover can take over. Guardian also picks a sensible triage model when none is configured.
36. v0.316.1

    Guardian and tool-selection bug fixes

    • Guardian stops proposing pointless channel restarts. A quiet Signal channel — no inbound in 72h — reflects your activity, not daemon health, so it no longer escalates to a Red alert; it’s at most an informational note, and Guardian validates any restart target against real channel accounts before proposing one.
    • MIRA stops claiming it lacks a tool it has. With adaptive tool selection on, MIRA now knows how many tools are loaded versus loadable on demand, and searches before telling you a capability is unavailable — fixing cases where a not-yet-loaded tool was wrongly reported as missing.
37. v0.316.0

    Built web apps work behind a reverse proxy

    • Open your built web apps from anywhere — including behind a reverse proxy. MIRA now serves each app the coding agent builds from its own main URL, at /a//. Because that is the same address you already expose, built apps open correctly behind a reverse proxy (Traefik, Caddy, nginx) or tailscale serve — no separate app port to expose, and no extra proxy config. They keep working on your LAN and from the mobile app too.
    • Isolation preserved. Untrusted, model-generated app code still runs in a sandboxed frame with its own opaque origin, so it cannot read your MIRA session or call the API even though it is served from the same host.

    Open built web apps
38. v0.313.0

    Guardian sentinel: faster alarms, reliable delivery, one-click enable

    • Faster down-alarms. The “MIRA is down” alarm now fires immediately when the sentinel declares MIRA down; the optional local-model triage that adds detail runs afterward, so a slow or unavailable model can never delay the alarm.
    • No more silent failures. If an alarm reaches no device, that’s now treated as a failure — logged loudly and recorded — instead of looking like a success. The Guardian panel warns when the sentinel is watching but can’t reach anyone, and checks this at startup.
    • One-toggle enable. Turning on the liveness sentinel in Settings → Guardian now automatically registers and starts it as its own supervised service, and turning it off stops and unregisters it — no separate install step (the CLI commands remain for headless setups).
    • Configurable logging. The sentinel shares MIRA’s main log file by default, or point it at its own file under Settings → Guardian → Sentinel log file.

    For a down-alarm to reach you while MIRA is offline, register at least one push device — open MIRA in a browser and allow notifications.

39. v0.311.0

    Guardian sentinel installer, now on macOS and Windows

    • The independent Guardian liveness sentinel — the watchdog that keeps watching even when MIRA crashes, hangs, or restart-loops, and raises a direct alarm to your device — now installs as a supervised service on all three desktop platforms, not just Linux.
    • mira guardian-install registers the sentinel as its own service, deliberately separate from the main MIRA service so it outlives a MIRA crash: a systemd unit on Linux, a launchd agent on macOS, and a dedicated service on Windows. mira guardian-uninstall removes it, and mira uninstall cleans up both.
    • Still off by default — enable and tune it under Settings → Guardian → Liveness sentinel, then run mira guardian-install.
40. v0.310.0 covers v0.307–v0.310

    The fully independent, agentic Guardian

    • Agentic triage. Guardian now investigates before it diagnoses — actively calling read-only tools for a full health snapshot and logs, its built-in docs, and relevant past context, then reasoning over what it finds. Fail-closed local-only throughout.
    • Delivered in MIRA’s voice when it can. While MIRA is up, Guardian hands its message to MIRA over a local shared-secret endpoint, so you hear it across your usual channels — Signal, Telegram, email — with direct web-push as the fallback.
    • Optional full-time watch. An opt-in setting lets Guardian own the whole watch and triage, running even while MIRA is up, while MIRA’s in-process watcher stands down so the two never double-alert.
41. v0.306.0

    Independent triage in Guardian’s own process

    • With a local model configured, Guardian runs a real, fail-closed local-only triage turn in its own process — reasoning over the health data to deliver a charter-voiced alert with a concrete next step, independent of a down MIRA. If no local model is reachable it falls back to the plain alarm, so an alert never fails to fire.
42. v0.305.0

    Alarms carry MIRA’s last-known health

    • A “MIRA is down” alarm now also reports what Guardian last saw — e.g. “last health check 2h ago showed Red: db.integrity, disk.free” — so you get context, not just “it’s down.”
43. v0.304.0

    Guardian installs as its own service

    • mira guardian-install / guardian-uninstall register Guardian as its own service unit, deliberately not bound to MIRA’s, so it survives a MIRA crash. Linux/systemd today; macOS and Windows to follow.
44. v0.303.0

    Out-of-process liveness sentinel

    • mira guardian-watch is a separate, supervised process that probes MIRA’s health and, if MIRA goes down for a sustained window, sends a direct web-push alarm — working even with MIRA fully offline. Off by default.
45. v0.302.0

    Universal duty-of-care safety floor

    • A short, non-overridable safety instruction now rides every user-facing turn, not just companion chats: never describe methods of self-harm, and take self-harm or acute physical symptoms seriously — with warmth and a crisis line. It’s the final word in the system prompt, so no persona or setting can silence it.
46. v0.301.0

    Guardian gets its own voice and a tiered local model

    • The watchdog now speaks in its own charter — quiet, precise, non-alarmist — and runs a tiered local model: a light model for routine notes, escalating to a stronger one only for real triage. Both tiers are fail-closed local-only. Configurable in Settings → Guardian.
47. v0.300.1

    Web-app links, service-account CLI resolution, automation spawns

    • Built web apps always open at their link. If a build names its single page something other than index.html (e.g. game.html), MIRA promotes it, so the app stays discoverable and openable.
    • Honest web-app links. MIRA only ever hands you a URL a tool actually returned — never a guessed or reconstructed one — and reports a failed build plainly instead of inventing a link. In the web chat, app links now open in a new browser tab, so opening a built app never navigates you away from the conversation.
    • External coding CLIs resolve under a service install. claude and opencode are now found when MIRA runs as a supervised service — it looks under the configured data directory and the owning user’s home, fixing “CLI not on PATH” under a Windows or systemd service.
    • Scheduled automations can spawn background tasks. An automation’s turn now carries caller identity, so delegating long-running work from a scheduled task no longer fails instantly.

    Open built web apps
48. v0.300.0

    Provider & tooling hardening

    • Portable tool calls. Tools use a portable schema dialect, with a registration-time linter that warns when any tool — including MCP tools — uses something a provider can’t accept.
    • The provider you pick is the provider that runs. Your selected model provider now drives the entire turn, for every provider.
    • Clearer failures. Uniform, legible provider errors; failover aggregates each provider’s reason, with a concise per-turn summary.
    • Trustworthy health signals. A primary provider going down is raised as a persistent health degradation that auto-clears on recovery.
    • Bad models caught at config time. Saving a provider runs a real 1-token generation test that catches deprecated or unauthorised models a plain catalog listing would miss.
49. v0.299.0

    Context management + cross-provider caching

    • Long conversations, managed. Threads are packed to a token budget you set (Settings → Agent). When a thread grows past the budget, older turns fold into a rolling summary — facts, decisions, open threads, preferences — while recent turns stay verbatim, with a safeguard that captures each turn before it can be dropped so nothing is silently lost.
    • Prompt caching that works across providers, with cached-token accounting and per-turn cache instrumentation.
    • Tool calls that work on every provider. Tool schemas are normalised per provider, with real API errors surfaced instead of silent failures.
50. v0.298.0

    Keep conversations on-device

    • Fail-closed, local-only provider failover — MIRA won’t silently fall back to a cloud provider when a local one is unavailable.

    Keep conversations local
51. v0.297.0

    Remote access

    • Reach your self-hosted server from anywhere over Tailscale — including a docker-compose sidecar recipe.

    Remote access
52. v0.296.0

    Built web apps, live

    • The coding agent serves the apps and games it builds at a clickable link.

    Open built web apps
53. v0.295.0

    Self-update & rollback

    • Update MIRA and roll back to an earlier build from a new Settings → Updates card.

    Updating & rolling back

Older releases and full notes live on GitHub