Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments

Terminal-Universe. Turning Agent Trajectories into Scalable Terminal Environments. By Jie Wu and thirteen others, from the Qwen Team at Alibaba Group and Tsinghua University. Published on the third of September. No code repository is linked to it.

Terminal-based code agents have been running long enough that their trajectories have accumulated at scale. Realistic executable environments have not. That asymmetry matters because environments are what agent post-training actually requires. An environment can be re-queried into many verifiable tasks and gives back execution feedback when an agent acts in it. A trajectory is a single frozen demonstration: you can imitate it, but you cannot ask it a new question or find out what would have happened if the agent had done something else.

The move is to notice that the two things are less far apart than they look. The tool-execution history recorded in an existing trajectory exposes the structure and contents of the environment the agent was running in. The environment left its fingerprints all over the transcript. So rather than generating environments from scratch, Terminal-Universe reconstructs them from the trajectories themselves, turning each trajectory into a reusable environment and then exploring it to synthesize new tasks and continued interactions.

Reconstruction works by replaying the file operations a trajectory recorded, running them in order to restore each file to the state it was in before the agent modified it. What that yields is a partial workspace, and partial is the operative word: a trajectory only ever touches the files the agent happened to reach, so everything it never opened is missing. A completion agent then supplies those missing files and the dependencies they need. On the recovered workspace, two things can now be built. The original intent task, which is the job the agent was doing when the trajectory was recorded, and entirely new tasks that nobody has attempted in that environment. From there the system scales along two complementary axes. For breadth, it mines directional dependency relations between related environments and synthesizes cross-workspace queries that span multiple codebases at once, which is what developers routinely do in real work and what a single-repository task never captures. For depth, an initial single-turn query is extended into a multi-round session, driven by a user agent, so the environment captures iterative feedback and requirement refinement rather than one request answered once.

Applied to public terminal agent trajectories, this produces roughly thirty-seven thousand task-sufficient environments, which is the number that tells you whether the reconstruction idea survives contact with real logs rather than curated ones. Supervised fine-tuning of Qwen3.5-27B on that corpus improves single-round performance on Terminal-Bench 2.1 by eleven point nine points, and multi-round performance on EvoCode-Bench v2 by thirteen point eight points. The multi-round number being the larger of the two is consistent with what the depth axis was built for, since a session that captures refinement is the part a frozen demonstration cannot supply at all.

The framing worth keeping is that the trajectories already sitting in everyone's logs are not just demonstrations to imitate. They are recordings of environments, and an environment can be asked new questions.

Terminal-Universe. Turning Agent Trajectories into Scalable Terminal Environments. By Jie Wu and thirteen others, from the Qwen Team at Alibaba Group and Tsinghua University. Published on the third of September. This is the long version: the whole paper rather than the abstract.

Terminal-based code agents have been running long enough that their trajectories have piled up at scale. Executable environments have not. The paper opens by insisting these are not interchangeable resources, and the distinction has to be exactly right, because everything else follows from it.

A trajectory is a fixed record. Its quality is capped by whatever policy model produced it, and critically, you cannot check whether the changes it made to the codebase were actually correct. You can imitate it and that is all. An environment has none of those limits. The same task can be attempted again by a stronger model, the result can be verified by tests you wrote, and harder tasks can be posed on the same workspace. For post-training, the environment is therefore the resource that repays scaling. Expert-authored benchmarks show what good looks like, pairing every task with a container, an instruction and an executable verifier, but that reliability comes from manual effort, which is exactly what caps how many exist.

Three existing routes scale environments, and each has a characteristic ceiling. Repository-based methods use git history: roll a real repository back to just before a bug was fixed, take the original bug report as the task, and reuse the tests that shipped with the fix. Perturbation methods take a repository that passes its tests, inject a bug, and ask an agent to repair it, which yields many tasks from few repositories but makes every single task a repair task. Task-conditioned synthesis generates task and environment together from scratch, guided by categories or skill graphs, which gives control over coverage but ties the environment to no real project at all, so its realism depends entirely on the generator, and generators tend to produce small tidy workspaces rather than real code.

Reconstruction runs in two stages. First, deterministic replay: the recorded file operations are replayed to restore each file to its state before the agent changed it, deliberately holding back the agent's own edits so the workspace starts unsolved. That matters, because an environment that arrives already fixed is not a task. Second, agentic completion: replay only reaches files the trajectory happened to touch, so a completion agent supplies the missing files and dependencies, and does so without leaking the solution. On the recovered workspace the system then re-queries in three ways. Within a single workspace it recovers the original intent and synthesizes novel tasks. For breadth it mines directional dependency relations between related environments and builds cross-workspace queries spanning multiple codebases, which is what developers routinely do and what single-repository tasks never capture. For depth it extends a single-turn query into a multi-round session driven by a user agent, capturing iterative feedback and requirement refinement.

Across thirty-eight thousand two hundred and ninety-four evaluated terminal environments and one thousand nine hundred repositories, task-grounded assessment identifies thirty-seven thousand two hundred and seventy-three fully sufficient environments. Know the composition before assuming generality: Python dominates at eighty-four point seven percent of primary languages, and data processing, DevOps and security together account for over eighty percent of technical domains. Fine-tuning Qwen3.5-27B on the resulting corpus improves single-round performance on Terminal-Bench 2.1 by eleven point nine points and multi-round performance on EvoCode-Bench by thirteen point eight. And the comparison that most directly tests the thesis is one the abstract does not mention: re-solving the recovered tasks beats fine-tuning on the source trajectories themselves. The reconstruction is worth more than the recording it came from.

The authors list three limitations and they are the right three. All workspaces use a standard Ubuntu container rather than tailored per-repository environments, so edge cases needing specialized system dependencies or complex compilation will have reduced fidelity. The domain, language and toolchain distribution is fundamentally bounded by the source trajectories, which the eighty-four point seven percent Python figure makes concrete. And a single teacher model generates the tasks, the solutions and the verifiers, so its capability gaps limit coverage and, more troublingly, an error it makes in a solution can be missed by the tests it also wrote. They suggest multiple teachers and an independent model for verifier construction.

There is a nice scaling observation buried in the discussion. Richer source trajectories, with multi-file manipulation and long tool-use chains, expose more workspace state and therefore support harder synthesized tasks. And multiple sessions on the same workspace can be replayed together, merging what each exposed into one reconstruction more complex than any single trajectory could recover. Which means the resource improves as agents get more capable. The logs you are already producing are not just demonstrations to imitate. They are recordings of environments, and an environment can be asked new questions.