Paper Walkthrough: Terminal-Universe — Turning Agent Logs Back Into Reusable Execution Environments

Replay the file operations recorded in an agent trajectory, have a completion agent fill in what's missing, and you get an executable workspace back. The pipeline yields 37.3k environments and lifts Qwen3.5-27B by 11.9 points on Terminal-Bench 2.1.

Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments

A recording plays once; a soundstage shoots forever

Think about a film that has already wrapped. If all you have is the finished cut, the only thing you can do is watch it. Bad take? Too late. But if the set and the gear are still standing, you can reshoot the same script with a better actor, or bring in an entirely different script.

Terminal coding agents have the same split. The records of what agents did — trajectories — have piled up as public datasets. Executable environments have not. The trajectory is the finished cut; the environment is the soundstage.

This paper takes the surplus of finished cuts and rebuilds the soundstage from them. The original title is "Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments" (arXiv:2609.04148, Qwen Team / Alibaba Group and Tsinghua University, published 2026-09-03).

The abstract, restated: as terminal-based code agents have become prevalent, trajectories have accumulated at scale while realistic, executable environments remain scarce — yet environments are what agent post-training actually requires, since each can be re-queried into many verifiable tasks and returns execution feedback, whereas a trajectory is a single frozen demonstration. The authors observe that the tool-execution history inside existing trajectories exposes the structure and contents of the environment they ran in, which makes it possible to reconstruct that environment from the trajectory itself. Terminal-Universe replays the recorded file operations to restore each file to its state before the agent modified it, yielding a partial workspace; a completion agent then supplies the missing files and dependencies. On the recovered workspace it both reconstructs the original intent task and synthesizes entirely new ones, then scales tasks along two axes: breadth (cross-workspace queries spanning multiple codebases) and depth (multi-round sessions driven by a user agent). Applied to public terminal agent trajectories it produces 37.3k task-sufficient environments; supervised fine-tuning of Qwen3.5-27B on that corpus improves Terminal-Bench 2.1 by 11.9 points and EvoCode-Bench v2 MT@4 by 13.8 points.

Why an environment beats a trajectory

The argument in §1 is blunt. A trajectory is a fixed record whose quality is capped by the policy model that produced it, and there is no way to check afterward whether the changes it made to the codebase were actually correct. An environment carries neither limitation: the same task can be re-solved by a stronger model, the result can be checked by your own tests, and harder tasks can be posed on the same workspace. So the environment is the resource worth scaling.

Existing approaches fall into three routes (§1, §2). Repository-based methods roll a real repo back to the state just before a historical bug fix, use the original bug report as the task, and reuse the tests that shipped with the fix as the verifier. Perturbation methods inject bugs into healthy repositories — many tasks from few repos, but every task is a repair task, bounded by the source repos and the kinds of bugs you can inject. Task-conditioned synthesis generates task and environment together from scratch; coverage is controllable, but because the environment is tied to no real project its realism rests entirely on the generator, which the paper notes tends to produce small, tidy workspaces rather than real code. Across all three, environment construction either starts from an existing environment or is welded to a freshly generated task. Trajectories, as observations of the environments they ran in, were left on the table.

The inversion: tool calls leak the environment

The tool calls recorded in a trajectory already expose what was there. Read shows file contents; Write and Edit show how the workspace changed (§1). That is enough to rebuild an executable copy. Reconstruction runs in three stages (§3.1).

Symbol by symbol: $\tau$ is the recorded trajectory. $E$ is the real environment it ran in, which you do not have. $\widehat{E}_{0}$ is the partial workspace that replay alone recovers, and $\widehat{E}$ is the completed workspace used to approximate $E$. The paper is explicit that this recovery is inherently lossy — unaccessed files, implicit system dependencies, and external network resources leave no trace in the trajectory.

Stage 1 (deterministic replay) walks the read/write/edit operations in chronological order and keeps, for each touched path, the earliest version visible in the trajectory. Files the agent created are excluded, and the agent's own edits are stored separately for later verification. That is what guarantees the workspace starts unsolved.

# Walk the trajectory's file ops in time order, keeping only "before the agent touched it"
initial = {}
for op in sorted(trajectory.file_ops, key=lambda o: o.time):
    if op.path in created_by_agent:      # skip files the agent itself created
        continue
    if op.path not in initial:           # keep only the earliest observed version
        initial[op.path] = op.content_before
agent_edits = collect_changes(trajectory)  # set aside for verification

Since the trajectory only exposes the paths the agent touched — and often only part of a file — $\widehat{E}_{0}$ is always full of holes.

Four ways to re-query one environment

Reconstruction alone does not exhaust an environment's capacity, so the paper defines four re-querying mechanisms (§3.2): Intent Recovery (rebuild the original task), Single-WS (synthesize new tasks inside one workspace), Cross-WS (breadth, by linking related workspaces), and Multi-Round (depth, by extending a query into a session).

Cross-WS begins with a nearest-neighbor search. An agent profiles each workspace's technical domain and implemented capabilities, TF–IDF retrieval proposes candidate pairs, and an LLM judge marks directional dependency edges where a target workspace lacks a capability the reference already implements. Which candidates surface at the top depends entirely on how you measure similarity.