Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments

Jie Wu, Zhenru Zhang, Beichen Zhang, Xuwu Wang, Yuhui Su, Mouxiang Chen, Peng Wang, Zhihai Wang, Que Shen, Hao Zhou, An Yang, Fei Huang, Yujiu Yang, Dayiheng Liu

Terminal-Universe reconstructs executable environments from raw agent trajectories to scale training data.

How can we transform static, recorded agent trajectories into reusable, executable terminal environments to scale agent training?

Agent trajectories are frozen records of past work, but effective post-training requires interactive, executable environments where models can be tested and re-solved. Terminal-Universe reconstructs these environments by replaying recorded file operations and using an agent to fill in missing dependencies, turning static logs into reusable workspaces. This pipeline generates 37.3k verifiable environments, improving single-round performance on Terminal-Bench 2.1 by 11.9 points and multi-round performance on EvoCode-Bench v2 by 13.8 points.

Paper Primer

The core mechanism hinges on a two-stage reconstruction: deterministic replay recovers the file states directly exposed by the trajectory, and agentic completion restores the latent context needed to make the workspace solvable. This turns a single, fixed demonstration into a sandbox where new tasks can be synthesized and verified.

The framework scales utility through four re-querying methods: Intent Recovery (reconstructing original tasks), Single-WS (synthesizing new tasks within a workspace), Cross-WS (connecting related codebases), and Multi-Round (extending tasks into interactive sessions). The system is like a forensic reconstruction: it reads the "footprints" of past tool calls to rebuild the room, then invites a new agent to solve a fresh puzzle inside.

Re-solving tasks in reconstructed environments significantly outperforms simple imitation of raw trajectories.

Training on Intent Recovery data (re-solved tasks) yields an average score of 52.1 on Terminal-Bench 2.1, compared to 36.7 for imitation learning on the same source trajectories.

Agentic completion is essential for environment sufficiency.

Deterministic replay alone leaves most terminal workspaces task-insufficient; adding agentic completion increases the sufficiency rate from 40.2% to 93.5% for terminal environments.

Why is this approach better than building environments from scratch or using repository history?

Generating environments from scratch often produces tidy, unrealistic workspaces, while repository-based methods are limited by the availability of historical git commits. Terminal-Universe leverages the vast, existing pool of agent trajectories to capture realistic, complex engineering scenarios that are otherwise difficult to synthesize.

What is the primary bottleneck for this framework?

The diversity and quality of the reconstructed environments are fundamentally bounded by the source trajectories. If the original trajectories lack complex tool-use chains or multi-file manipulations, the reconstructed workspaces will be similarly limited in their ability to support demanding tasks.

Researchers can now treat raw agent logs as a scalable source of interactive training data, shifting the focus from manual environment curation to automated reconstruction and task synthesis.

Turning Trajectories into Environments

We reframe agent trajectories as reusable environments, enabling scalable task generation via deterministic replay and agentic completion.

Terminal‑based code agents generate massive amounts of trajectories, yet realistic, executable environments remain a bottleneck. A trajectory is a single frozen demonstration, while an environment can be re‑queried into many verifiable tasks and provides feedback for post‑training improvement.

We treat each recorded trajectory as a seed that can be turned into a full, executable environment.

**Figure 1.** **Overview of Terminal-Universe.** A trajectory and an environment are two views of the same episode, so prior work rolls out a trajectory from an environment while we invert the mapping and recover an environment from a trajectory (left). Reconstruction proceeds in two stages, deterministic replay followed by agentic completion (middle). Each recovered environment is then re-queried within one workspace, across multiple dependent workspaces, or over multiple user rounds (right). Figure 2 details each mechanism.

The key shift is viewing trajectories not as fixed logs but as dynamic seeds for reusable environments.

Environment Scaling Strategies

We situate Terminal‑Universe among prior work on environment scaling, task synthesis, and interactive agents.

Prior work scales executable workspaces via three distinct routes: recovering repository states from development histories, modifying existing workspaces, or synthesizing task‑specific environments from generated specifications.

Task synthesis methods also fall into two broad families: top‑down pipelines that generate task‑environment pairs from abstract categories or seeds, and environment‑grounded approaches that derive tasks from existing codebases and project context.

Interactive benchmarks now model agents as multi‑turn participants. Systems such as InterCode, SWE‑INTERACT, SWE‑Together, ICAE‑Bench, and EvoCode‑Bench v2 evaluate agents in dynamic dialogues, progressively revealing requirements or sequential development requests.

Section 3.1 details Terminal‑Universe’s environment reconstruction in three stages: deterministic replay of recorded file operations, agentic completion to fill missing context, and filtering to retain only workspaces sufficient for the recovered task.

Deterministic replay recovers earliest file versions for accessed paths, excluding files created by the agent; agentic completion then generates missing files and dependencies; finally, a read‑only judge filters out workspaces that lack enough context for the task.

The Terminal-Universe Framework

Re‑querying extracts new tasks from recovered workspaces using four complementary mechanisms.

Reconstructing environments gives us runnable workspaces, but without a strategy to query them we cannot tap their latent capabilities. The section therefore introduces four re‑querying mechanisms that turn a workspace into a source of new tasks.

Agentic Completion predicts missing files and commands so that a partially recorded trajectory becomes an executable environment.

How does Agentic Completion differ from simply replaying the recorded commands?

Replay replays exactly what was recorded, which may stop early or miss files; Agentic Completion predicts and inserts the missing pieces, turning an incomplete trace into a runnable environment.

Re‑querying defines how to harvest new tasks from recovered workspaces, using four complementary mechanisms that explore breadth and depth of the latent capability space.

Why not generate tasks directly from the original trajectory instead of re‑querying?

The original trajectory encodes only the demonstrated task; re‑querying explores the broader capability space of the environment, enabling novel task generation beyond the recorded behavior.

Candidate 1: “Implement a function in

Candidate 2: “Add command‑line argument parsing to

Candidate 3: “Create a unit test suite for

Candidate 4: “Refactor

Candidate 5: “Document the project with a README describing usage.” – grounded, adds documentation.

Random selection picks Candidate 3 for rollout, because it satisfies all three constraints and introduces a new test file.

Even with a tiny workspace, the generator can produce diverse, verifiable tasks, illustrating how Single‑WS synthesis expands the capability space without needing large codebases.

**Figure 2.** Framework of Terminal-Universe. A recorded trajectory is replayed and completed into an executable workspace, which is retained only when it is sufficient for its task (left). The recovered workspace supports Intent Recovery, Single-WS synthesis that explores a workspace to propose novel task candidates, Cross-WS synthesis via workspace profiling and relation mining, and Multi-Round continuation that extends an initial query into an iterative session.

**Figure 3.** Pass/fail patterns in Multi-Round sessions.

Verification and Filtering

We build an Agentic Verifier to construct, roll out, and filter task environments for reliable data.

Generating executable tasks from raw agent trajectories requires a trustworthy way to confirm that the reconstructed workspace actually satisfies the intended behavior. Without such a gate, downstream models would learn from noisy or incorrect examples, undermining the whole pipeline.

The verifier is a dedicated agent that writes a self‑contained pytest suite tailored to the task specification and the files present in the workspace, then runs that suite to certify the final state.

How does the Agentic Verifier differ from a conventional unit‑test suite?

Standard unit tests are static and written by developers ahead of time; the Agentic Verifier synthesizes tests at runtime, conditioning on the exact task description and the concrete files produced by the rollout, so it can enforce task‑specific contracts that generic tests cannot capture.

The verifier scans the prompt, detects the required

It also adds a type‑check test

After the rollout finishes, the generated

If the rollout omitted the type check, the second test would fail, causing the trajectory to be discarded.

The verifier guarantees that the workspace not only contains the requested code but also satisfies the exact behavioral contract encoded in the generated tests.

Instantiate the teacher model inside the task container using the Claude Code scaffold.

Decode the model output with temperature 1.0 and top‑p = 0.95 over a 256 k‑token context window.

Limit each turn to 65 536 tokens; trigger proactive summarization at 176 k tokens.

Allow up to 500 agent turns or a four‑hour wall‑clock timeout, whichever comes first.

Provide containerized network access so the rollout can fetch any missing dependencies.

Verification and data selection pipeline

**Figure 4.** Mean workspace size before and after agentic completion.

**Table 13.** Workspace complexity before and after agentic completion. Cells report median / mean.

**Figure 7.** Core environment-reconstruction flow.

After verification, only trajectories that pass the generated test suite are kept, yielding 31 977 high‑quality SFT demonstrations that feed the four re‑querying variants.

Empirical Results

Key performance gains of Intent Recovery over baseline SFT across benchmarks.

The paper reframes recorded agent trajectories as reusable execution environments, filling missing workspace state with agentic completion and generating new tasks via re‑querying.

Qwen3.5‑27B attains 58.1 % pass rate on Terminal‑Bench 2.1, surpassing the base SFT by 11.9 %.

Table 3 reports the 58.1 % figure for the Full Mixture model.

It extends the original Terminal‑Bench by adding richer task specifications and stricter verification, making the benchmark harder for agents to solve.

How does Terminal‑Bench 2.1 differ from the earlier 2.0 version?

Version 2.1 adds cumulative verification of intermediate states and richer goal specifications, so an agent must not only reach the final goal but also keep the workspace consistent after every turn.

Intent Recovery yields sizable performance lifts over source‑trajectory SFT across both single‑ and multi‑round benchmarks.

Ablation Studies

We isolate each design choice to see how it impacts performance.

We run a series of ablations to answer whether each component of the pipeline is essential.

Re‑solving recovered tasks improves performance over directly imitating the original trajectories.

Table 4 shows Intent Recovery achieving 52.9 % average versus 51.3 % for source‑trajectory SFT.

Agentic completion adds a measurable boost beyond deterministic replay.

Training on completed environments yields 52.9 % versus 48.7 % for replay‑only.

Verifier filtering improves results on harder cross‑workspace tasks.

Cross‑WS with verifier reaches 55.4 % versus 53.2 % without.

Combining single‑workspace and cross‑workspace synthesis yields the highest score.

Mixed data reaches 58.4 % Terminus2‑XML versus 56.4 % for single‑workspace alone.

Cross‑workspace tasks generate longer, more complex trajectories (≈1.6× turns, 1.9× tool calls, 1.5× tokens) and make the teacher harder, yet their inclusion raises overall performance.

Multi‑round depth expansion raises the case‑score substantially.

Single‑WS + Multi‑Round achieves 76.9 % case score versus 71.9 % for Single‑WS alone.

Doubling the corpus by adding new environments yields the largest MT@4 gain.

Environment expansion lifts MT@4 from 18.4 % to 21.0 %.

Training on SWE intent‑recovery trajectories transfers to the terminal benchmark.

Average score rises from 47.0 % to 50.0 %.

**Figure 5.** Language and domain composition of reconstructed terminal workspaces.

Case Studies

Case studies illustrate reconstruction, cross‑workspace synthesis, and multi‑round user queries in Terminal‑Universe.

Terminal‑Universe turns recorded agent trajectories into reusable execution environments by filling missing workspace state (Agentic Completion) and re‑querying to generate new tasks.

Intent Recovery bypasses the agentic verifier, keeping it directly comparable to the original supervised‑fine‑tuned (SFT) source trajectory.

E.1 showcases reconstruction and reuse on a TypeScript‑React project called MirrorBrain, whose workspace supports multiple coding tasks without missing source files.

**Table 15.** MirrorBrain reconstruction and re-querying trace.

The source‑trajectory stage refines React interface components and a focused test covering navigation, controls, review cards, and draft editing while preserving existing workflows.

Deterministic replay recovers the project manifest, test configuration, Fastify service, memory‑review and cache modules, integration adapters, and end‑to‑end fixtures.

Agentic completion preserves all replayed source and test files and adds root‑filesystem integration context, including a memory‑event fixture, OpenViking adapter, React context, and runtime logs.

Intent Recovery produces a cross‑component interface objective that spans navigation, tabs, pagination, candidate cards, and action buttons.

Single‑WS synthesis explores the completed workspace and generates five new tasks: shell‑event normalization, URL classification, client‑error handling, response‑schema alignment, and cache‑source reconciliation.

Trajectory evidence lists the replayed project paths (e.g., package.json, src/mirrorbrain‑mvp‑fixture.ts) and the added root‑filesystem artifacts (e.g., browser:101.json, mirrorbrain‑debug.log).

Recovered intent states: “Improve the MirrorBrain React interface by applying a polished, consistent, and accessible design across main navigation, subtabs, draft tabs, pagination controls, candidate cards, and action buttons, while preserving existing workflows and component behavior.”

Generated queries (Single‑WS) ask the system to normalize shell events, classify URLs, handle client errors, align response schemas, and reconcile caches.

E.2 traces cross‑workspace synthesis on two C RSA toolkits, where the target lacks a decryption program that the reference provides.

**Table 16.** Synthesis trace for the RSA toolkit dependency pair.

The read‑only reference (/app/workspaces/repo0) contains `rsa_keygen`.c, `rsa_encrypt`.c, `rsa_decrypt`.c, `rsa_sign`.c, and associated I/O directories.

The writable target (/app/workspaces/repo1) lacks `rsa_decrypt`.c but includes key generation, encryption, and signing files, plus a `task_file`/ directory for new tasks.

The capability gap is the missing decryption program; the reference reveals the private‑key loader, padding mode, and OpenSSL API calls needed to complete the encrypt/decrypt round‑trip.

The selected request asks the teacher to create `rsa_decrypt`.c in the target workspace, matching the reference’s API usage, error handling, and coding conventions.

Verifier checks cover compilation, round‑trip correctness, command‑line behavior, input paths, padding, and OpenSSL calls, while preservation tests ensure existing programs remain unchanged.

E.3 examines multi‑round user queries, showing interaction‑style distribution (Table 17) and detailed request excerpts across seven rounds (Table 18).

**Table 18.** Abridged user requests from the Multi-Round sensor-ingestion trajectory. Brackets ellipses mark omitted text. "Revision" corrects the current requirement; "conflict" replaces it.

**Table 18.** User requests across rounds.

Failure‑driven feature revision occurs when the incremental aggregation introduces random scaling, causing unstable aggregate values; the private verifier catches this, prompting the user to request a deterministic fix.

Controlled requirement conflict arises after the user decides to make alerts.json an append‑only history, shifting the product direction and driving subsequent extensions for reporting, reconciliation, and repair.

**Figure 8.** Verifier-guided multi-round continuation. A private verifier checks each round, while the coding agent sees only the subsequent natural-language requests.

```text /app/workspaces/ |-- repo0/ | |-- rsa_keygen.c | |-- rsa_encrypt.c | |-- rsa_decrypt.c | |-- rsa_sign.c | |-- input/ | | '-- plaintext.txt | '-- output/ | '-- decrypted.txt '-- repo1/ |-- rsa_keygen.c |-- rsa_encrypt.c |-- rsa_sign.c |-- input/ | '-- plaintext.txt |-- output/ | '-- decrypted.txt '-- task_file/ |-- input/ | '-- plaintext.txt '-- output/ ```

Data Sources

We detail the source corpora, deduplication process, and reconstruction statistics.

Appendix A lists the corpora we draw trajectories from, explains how we deduplicate and de‑contaminate SWE datasets, and reports the numbers of trajectories and reconstructed environments per source. Table 12 shows the raw trajectory counts and the resulting environment pools after filtering out view‑only or unsupported actions. Table 13 compares median and mean workspace complexity for the Terminal and SWE pools before and after agentic completion ($\hat{E}_0$ vs. $\hat{E}$).

**Figure 7.** Summarizes the core reconstruction and sufficiency stages.

Reconstruction Details

How the system rebuilds a workspace from partial traces and evaluates its usefulness.

Reconstruction starts by normalizing raw file‑operation logs into a single ordered event stream. Reads, writes, and edits are treated uniformly, and the observed content of read‑only files is preserved.

For modified files we keep the content visible before the first change; any later edits or files created by the agent are omitted from the replayed workspace. This yields a partial but faithful snapshot of the original project.

The completion agent receives the recovered request, the partial workspace, and a file inventory. It fills missing context by creating new files, completing partial ones, and configuring dependencies, but it must never implement the requested task.

Reconstructed projects are placed under /app; any files accessed elsewhere in the filesystem are stored separately. This packaging keeps the workspace self‑contained for downstream evaluation.

Manual inspection of 30 randomly sampled terminal completions found that 22 contained only task‑relevant support files, while eight introduced substantial extra files. No completed workspace contained a solution to the target task.

Workspace sufficiency is evaluated by an agentic judge that inspects each reconstructed workspace with read‑only shell and file tools. A workspace is deemed task‑sufficient when its source, configuration, data, and structure give a capable agent enough context to attempt the task.

### ROLE & GOAL You are a workspace completion agent. Complete a Docker workspace so that the given task becomes solvable, but NOT solved. ### RUNTIME INPUTS Task the future agent must solve: <`ORIGINAL_INSTRUCTION`> Current workspace files (container-absolute paths; project root and working directory: /app): <`DOCKER_LAYOUT_FILES`> ### COMPLETION CONTRACT **Objectives** 1. Make the task solvable. Create missing project files or complete partial ones, including configs, fixtures, scripts, data, schemas, manifests, and support code that the task clearly depends on. 2. Do NOT solve the task. Do not create the requested implementation, fix, feature, configuration change, or output. 3. Create realistic project context with consistent naming, plausible structure, and enough working surrounding code for a future agent to investigate. **Rules** - Prefer source code and data, followed by build/config files and referenced scripts. Create documentation only when explicitly required or consumed at runtime. - Existing non-target code may be substantial, but do not add tests for the not-yet-implemented target or comments that reveal its exact solution location. - Keep code syntactically valid and consistent with the workspace's language, framework, versions, and style. - Use network access or install packages only when needed to restore dependencies required by the existing project. - You may create missing files and complete partial files, but do not make the change requested by the task.

**Table 14.** Source breakdown of workspace sufficiency under recovered intents after agentic completion.

Failure analysis reveals that task‑insufficient workspaces typically miss critical source files, task scripts, input data, configuration, or deployment descriptors. Missing tests, manifests, or package __init__ files are common signals of a partial source tree.

The judge prompt instructs the evaluator to return a binary judgment (sufficient/insufficient) together with a brief evidence‑based reason, listing present and missing critical paths. This structured output guides downstream agents in pinpointing what still needs to be reconstructed.

Re-querying Details

Details of how re‑querying prompts and generation mechanisms are structured.

All four re‑querying variants share a common pattern: the request encodes an observable goal while leaving the concrete implementation to the coding agent.

Each Cross‑WS pair is mounted as repo0 and repo1 under /app/workspaces; the generation agent picks one as a writable target and the other as a read‑only reference, and the verifier ensures the reference remains unchanged (see § 3.3).

Prompt templates preserve the generator’s inputs, instructions, and output schema; repeated rules and examples are abbreviated, and placeholders written as <…> are filled at runtime.

Intent Recovery receives a cleaned task description, a chronological conversation trace, and file evidence; a single‑round trajectory uses the sole substantive user request directly, while multi‑round trajectories treat the first substantive request as the task topic and only incorporate later requests that clarify or constrain that same topic.

The Intent Recovery prompt asks the model to act as a “task intent reverse‑engineering expert”, preserving code symbols and outputting a JSON contract that includes a core objective, success criteria, mandatory constraints, and prohibitions.

Single‑WS Synthesis is given a path inventory and may inspect selected files with read‑only commands; it cannot modify the repository, access the network, or scan outside the workspace, and after deduplication it selects one grounded task per workspace.

The Single‑WS Synthesis prompt directs the agent to propose five diverse, verifiable terminal tasks for future coding agents, insisting on a clear goal, deterministic validation, and no exposure of secrets or external dependencies.

Cross‑WS Synthesis first profiles each workspace, uses TF‑IDF to retrieve nearby candidates, and labels each pair as similar, complementary, dependency, or unrelated; dependency pairs are selected under constraints that no workspace appears in two pairs and usage limits are respected.

For a dependency pair, the generation agent reads both repositories, assigns roles, and returns a task together with file evidence and three hidden dependency facts; the task must rely on at least three reference‑only details, name target files, define executable checks, and preserve existing behavior.

Three prompts support Cross‑WS synthesis: (1) Workspace Profiling, which extracts domain, language, frameworks, and capabilities; (2) Relation Judging, which classifies each candidate pair and, for non‑unrelated relations, produces a concrete coding task; (3) Dependency‑Gap Task Synthesis, which crafts a single task that forces the target to depend on the reference’s assets.

Multi‑Round User Queries continue a solved session by exposing only the next user message to the coding agent; after a failure the user asks for a correction without altering requirements, and after a pass the user may add a compatible extension.

During SFT training, trailing verifier‑failed rounds are removed, and only sessions with at least two passing rounds are kept; failed rounds remain with feedback for correction.

The Multi‑Round User Queries prompt instructs the model to role‑play the human user, classify the next request as a feature revision, extension, or conflict, and produce a concise, observable contract without revealing verifier internals.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers