Field noteNov 10, 20266 min read1 source

Reflection Mirror CLI 0.1.1 adds /fork, /web-provider, and sub-agent inspection

In one minute

Reflection’s changelog lists Mirror CLI 0.1.1 features for branching local agent work, inspecting sub-agent conversations and choosing a web-search provider. The changes matter to developers already using this terminal coding agent because they make sessions easier to separate and agent activity easier to inspect.

What happened

Reflection’s changelog identifies the CLI release as reflection-mirror-v0.1.1. One addition is /fork [name], which copies an idle local conversation and its working files into a new workspace. That gives a developer a way to preserve a current session while creating a separate workspace from its state. In practice, the command is framed around idle conversations, rather than a mechanism for duplicating any session at any time. The changelog does not describe conflict handling, what happens to external services or processes associated with the original session, or limits on what is copied.

The release adds in-app inspection of sub-agent conversations. This brings conversations generated by subordinate agents into the CLI interface rather than leaving the primary user only with a final result or high-level status. It also adds /web-provider, which lets users choose You.com, Tavily or Firecrawl for search and browsing. The selected provider is saved across launches, and You.com is the default. The notes do not specify whether these providers have different configuration requirements, costs or capabilities inside Mirror.

Other listed additions include /feedback for submitting feedback and reporting issues, display of recorded session usage, support for loading extensions directly from local source directories, batch extension approvals and visibility into failed or unapproved extensions in /extensions. Tools can require confirmation even when automatic approval mode is enabled. That distinction means automatic approval does not have to be an all-or-nothing policy for every tool action. The CLI also supports additional Gemini models and optional HTTP endpoints for in-memory agent traces.

The changelog describes changes beyond new features. It says transcript scrolling and streaming are smoother, with fewer redraws and stalls in long conversations; concurrency-safe tool calls can run in parallel; and persistent WebSocket connections are supported for compatible OpenAI Responses endpoints. It also lists more consistent web-search and browsing output, clearer tool-progress groups, expanded usage analytics and documented collection and opt-out controls. Fixes cover usage accounting, prompt caching, thinking-history replay, HTTP MCP client initialization and other behaviors. The notes do not give performance measurements, enumerate the additional Gemini models, or state which OpenAI Responses endpoints qualify for persistent WebSocket connections.

What the archive adds

New Runtime's earlier coverage described Mirror CLI's harness as an operational surface developers need to understand. This release is a new event on the same product, adding specific workflow and inspection controls rather than restating the original open-source announcement.

Trend signal

This supports the idea that harness architecture outlives model choice: Mirror's changelog emphasizes session management, provider selection, sub-agent visibility and tool approvals alongside model support. These controls shape how a developer works with the agent regardless of which supported model is selected. One release is evidence of product direction, not proof that the harness is more important than model capability in every workflow.

Why now

The changelog places these capabilities in the 0.1.1 CLI release, but does not explain why they were prioritized or connect them to a broader launch or market event. Their timing can therefore be described only as part of the product's ongoing development.

Why it matters

For teams already evaluating Mirror, the update makes it easier to separate work without losing the context of an idle conversation and to inspect what sub-agents are doing. Those are useful workflow controls: parallel agent activity is harder to trust when it is invisible, and a copied workspace can give developers a safer place to explore a change without disturbing the original session.

The release also groups several forms of operational visibility in one iteration: recorded session usage, extension approval state, sub-agent conversations and optional trace endpoints. None of those features proves that a workflow is safe or reliable. Together, however, they give an operator more places to inspect what the harness has done and where an extension or tool call requires attention. For a terminal agent that can work across files and execute tools, that operating surface can be as consequential as a new model option.

Provider selection may also matter where a team has a preferred search service or existing access arrangements. But the changelog does not establish that one provider performs better, costs less or is safer than another. Teams should treat the controls as operational flexibility, then test them in their own repository and review how tools request confirmation before relying on unattended work.

What happens next

  • Mirror will continue expanding its CLI workflow and agent controls. (6 months, 65%). Watch for: a subsequent CLI changelog adding or revising session, sub-agent or tool-approval features.

Limits and uncertainty

The changelog is a feature list, not an evaluation. It does not report adoption, reliability, speed improvements or the effect of /fork on larger workspaces. It also does not compare You.com, Tavily and Firecrawl, disclose their configuration or cost requirements within Mirror, or identify the additional Gemini models by name. Reflection does not state how sub-agent inspection is presented, how long conversations are retained, or which trace data an optional HTTP endpoint exposes. The operational behavior of local extensions, trace endpoints and confirmation requirements should be checked in the tool before a team relies on them in a production workflow.

Skill to build now

If your team uses Mirror, take one contained task and try /fork [name] on an idle session. Confirm which files appear in the new workspace, then inspect a sub-agent conversation and test the provider choice you expect your team to use. Record any differences in context, permissions or search output before standardizing the workflow. Also test a tool that should still require confirmation under automatic approval mode, so the team understands the effective boundary rather than assuming the setting behaves uniformly.

Reader takeaway

Mirror CLI 0.1.1 adds useful controls for people already using the tool: fork an idle conversation into a new workspace, inspect sub-agent activity and choose a persistent search provider. The release makes the harness more configurable and observable, but its changelog offers no evidence yet about measurable gains in speed, quality or reliability.

Evidence / sources

  1. 1github.com/reflection-oss/mirror/blob/main/CHANGELOG.md
All Field Notes

Next reads

Read next

Open the graph
  1. 01topicGeminiExplore the gemini topic hub.
  2. 02archiveField NotesOpen the latest editorial analysis.
  3. 03sourcesSourcesSee the original sources this archive cites.
Who read this page?Machine requests, hidden until opened

Loading the privacy-safe route aggregate...

Open the JSON contract