Skip to main content

​
August 12, 2026 — Recycling a stuck cloud machine works

  • ara_machine_reset returned cloud_machine_reset_unavailable for every call since it shipped, so an agent on an unusable machine had no way to recover it. Its live-session guard compared a session id against a mistyped parameter and the query could never execute. Rotation now succeeds and reports the machine generation it moved from and to.
  • The guard itself is unchanged in intent: a reset is still refused while another session is running on that machine, still applies to cloud machines only, and still never touches a person’s own computer.

​
August 12, 2026 — An agent can see and recycle its cloud machine

  • ara_machine_list reports the cloud machines a workspace’s sessions run on, each machine’s generation, how many sessions are still live on it, and how many repositories share it.
  • ara_machine_reset rotates the current session’s cloud machine so the NEXT run provisions a fresh one. Use it when a machine is unusable (out of disk, a wedged process, a corrupt checkout) and ordinary retries keep failing.
  • Rotation is not a wipe: the previous machine’s contents are not deleted, it is simply no longer selected and ages out normally. The current run is not repaired either, so start a new session to pick up the replacement.
  • Refused while another session is still running on that machine, so recycling can never pull a workspace out from under a teammate’s live run. Cloud machines only: a person’s own computer is never reset by an agent.

​
August 11, 2026 — Retry a session on a different model

  • ara_session_create and ara_session_send now accept optional model and reasoning_effort parameters, so an agent watching one of its own sessions stall or fail can retry it on another model instead of only reporting the failure.
  • Sending a model override to a live session always starts a new continuation run rather than mutating the one in progress: a run’s model is fixed at its first execution, the same way a composer retry works today.
  • Valid model ids are the closed Ara catalog (openai/gpt-5.6-sol, openai/gpt-5.6-terra, openai/gpt-5.6-luna, anthropic/claude-sonnet-4.6) or a connected organization byok: id; reasoning_effort is one of low, medium, high, or xhigh. Omitting either preserves today’s behavior.

​
August 11, 2026 — A shorter Connect Ara screen

  • The MCP connect screen no longer shows the requesting app and its requested access as two boxed panels. The app name and a one-line access summary sit in the prose above the workspace picker instead.
  • Nothing was dropped from what you consent to: the screen still names which app is asking and whether it receives full or only its requested access, and still states that stored secrets can be written or replaced but never read back.

​
August 11, 2026 — The shared agent skill names the session tools

  • The Ara skill that ara mcp installs for every coding agent now names the canonical session tools (ara_session_create, ara_session_events, ara_session_send, ara_session_get, ara_session_search, ara_session_cancel), so an agent reading it can run the whole loop instead of only the setup steps its description already promised.
  • It also records that ara_session_interact is a deprecated alias of ara_session_send. The alias still dispatches for existing callers, and is still deliberately absent from the advertised tool list.

​
August 7, 2026 — Organization memory on the capability plane

  • Eligible cloud sessions can use org-wide durable memory through ara.memory.list, ara.memory.read, ara.memory.write, and ara.memory.search.
  • Memory is organization-scoped markdown (L1 USER.md / MEMORY.md, semantic directories, and episodic/YYYY-MM-DD.md), not repository-scoped notes.
  • Settings → Memory shows the file tree, editor, history, and Dream now controls.
  • Available to every workspace by default. Operators retain ORG_MEMORY_ENABLED as an emergency global switch and may use ORG_MEMORY_ORGS as a temporary bounded override.

​
August 2, 2026 — One-command agent setup

  • ara mcp now configures every detected supported agent app, installs the shared Ara agent skill, and starts its native OAuth flow without an extra Ara confirmation prompt.
  • ara device is the short, idempotent path for installing this Mac as a full-access background Ara Device.
  • Ara agents can test authentication for fixed, curated HTTP MCP connections without receiving secret values or opening custom URLs from the API server.
  • Ara MCP remains the direct tool surface for coding agents; Ara Device is the separate native worker. The direct Streamable HTTP endpoint is https://api.ara.so/mcp/ara.

​
August 10, 2026 — Minimal standard CLI

  • ara mcp is now the only MCP setup and status capability. Its first run configures every detected client; later runs report organization, installation paths, connections, and last use without changing ready clients.
  • ara status, ara whoami, ara help, and ara --version provide the conventional discovery surfaces agents expect.

​
August 4, 2026 — Runtime conformance

  • The canonical exact-main check now runs the full four-case conformance corpus, including on a clean diff. This keeps the production baseline and changed-case checks aligned.
  • Its dynamic outcome markers are sentence-shaped rather than token-shaped, so Ara’s safety redaction does not hide the evaluator’s own visible result.
  • Case-derived nonce components are separated before interpolation as well, including the long failed-recovery case name.

​
August 7, 2026: Custom MCP server connections pin the verified address

  • Requests to a configured org MCP server (health checks, OAuth discovery and token exchange, gateway calls) now connect to the exact IP address the private-network guard verified, instead of resolving the server’s hostname a second time at connect time. A DNS name that answers with a public address during validation can no longer swap to an internal or link-local address for the actual connection (DNS rebinding). TLS still validates the server’s certificate against its hostname, so legitimate public MCP servers, including those behind CDNs that require SNI, are unaffected.
  • Follow-up: the OAuth discovery, registration, and token-exchange steps of this flow are now exercised in tests through an injected transport, so the private-network guard above is always the real one under test. Internal test tooling only; the flow’s outbound behavior is unchanged.
  • Follow-up: the guard’s DNS lookups are now cancelled the moment their caller gives up, instead of running to the OS timeout in the background. A custom MCP server whose nameserver stalls on purpose can no longer pile up pending lookup work on the API server; legitimate servers resolve exactly as before.

​
August 6, 2026: Org-MCP health-check hardening

  • Health checks for a configured org MCP server now validate every redirect hop against the private-network guard, not just the initial URL. A custom MCP server URL can no longer be used to reach internal or link-local addresses via a redirect. Legitimate public MCP servers are unaffected.