Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments

2026-09-04

Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments Jie Wu1,2,* , Zhenru Zhang1,‡ , Beichen Zhang1 , Xuwu Wang1 , Yuhui Su1 , Mouxiang Chen1 , Peng Wang1 , Zhihai Wang1 , Que Shen1 , Hao Zhou1 , An Yang1 , Fei Huang1 , Yujiu Yang2,† , Dayiheng Liu1,† 1 Qwen Team, Alibaba Group ‡ Project leader

2 Tsinghua University

† Corresponding authors

arXiv:2609.04148v1 [cs.AI] 3 Sep 2026

Abstract As terminal-based code agents become increasingly prevalent, the corresponding agent trajectories have accumulated at scale, while realistic, executable environments remain scarce. However, environments are what agent post-training actually requires: each one can be re-queried into many verifiable tasks and provides the execution feedback, whereas a trajectory is a single frozen demonstration. Rather than generating environments from scratch, we observe that the tool-execution history in the existing agent trajectories exposes the structure and contents of the environments in which they ran, making it possible to reconstruct those environments from the trajectories themselves. Thus, we introduce Terminal-Universe, a framework which turns each trajectory into a reusable environment and explores it for synthesizing new tasks and continued interactions. Specifically, Terminal-Universe replays the file operations recorded in a trajectory to restore each file before the agent modified it, yielding a partial workspace; a completion agent then supplies the missing files and dependencies. On this recovered workspace, we both reconstruct the original intent task and synthesize entirely new ones. Besides, we also scale the tasks for the corresponding environment along two complementary axes: breadth and depth, to reproduce a routine pattern of real engineering practice. For breadth, we mine directional dependency relations between related environments and synthesize cross-workspace queries spanning multiple codebases, as developers routinely do in real-world development. For depth, we extend the initial single-turn query into a multi-round session that captures iterative user feedback and requirement refinement via a user agent. Applied to publicly available terminal agent trajectories, Terminal-Universe produces 37.3k task-sufficient environments. Supervised fine-tuning of Qwen3.5-27B on this corpus improves single-round performance on Terminal-Bench 2.1 by 11.9 points and multi-round performance on EvoCode-Bench v2 MT@4 by 13.8 points.

1

Introduction

As terminal-based code agents become increasingly prevalent, the trajectories they produce have accumulated at scale, while realistic, executable environments remain scarce. This gap matters because a trajectory and an environment are not equally useful. A trajectory is a single, fixed record: its quality is bounded by the responses of the policy model that produced it, and we cannot check whether the changes it made to the codebase are actually correct. An environment has none of these limits, because the same task can be solved again by a stronger model, the result can be verified by our own tests, and harder tasks can be posed on the same workspace. For post-training, the environment is therefore the resource worth scaling. Expert-authored benchmarks show what a good environment looks like. Terminal-Bench (Merrill et al., 2026), for example, pairs every task with a custom container, an instruction, and an executable verifier. This reliability comes from manual effort, which also limits how many tasks can be built, while effective post-training needs far more environments than manual curation can provide. Supplying realistic, verifiable environments at training scale is therefore the challenge we address. Existing work scales executable environments in three ways. Repository-based methods build tasks from the git history of a real repository (Pan et al., 2024; Jain et al., 2025). For a bug that was fixed in the past, they use git to roll the repository back to the state just before the fix to form the environment, take the original bug report as the task, and reuse the tests that came with the fix to check the solution. Perturbation methods take a repository that passes its tests, inject a bug so that some tests now fail, and ask the agent to fix it (Yang et al., 2025; Lin et al., 2026). A few repositories can yield many tasks this * Work done during the internship at Qwen Team, Alibaba Group.

1

ı Trajectory–Environment Duality

Ď Re-query Methods

y Environment Reconstruction

Ì Recovered environments

Stage 1

Rollout ı Trajectory

Ë Env

Prior Work

˚ Deterministic Replay replay read/write/edit ops

Ë

Ë

Ë

Ë

ͳ partial workspace ı Trajectory Reconstruct Ë Env

ɶ Round 1

agent explores agent discovers the workspace a dependency

Stage 2

ü Agentic Completion

Reuse

¸ create missing files

ı New Trajectory

ʹ executable workspace

Terminal-Universe

i Round 2

ɶ Query

ɶ Query

i Round 3

Single-WS

Cross-WS

Multi-Round

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. way, but every task is a repair task, and the range of tasks is limited by the source repositories and the kinds of bugs that can be injected. Task-conditioned synthesis generates the task and its environment together from scratch, guided by categories or compositional axes (Gandhi et al., 2026; Ivison et al., 2026), skill taxonomies (Hua et al., 2026), or skill graph (Fan et al., 2026). These methods offer control over coverage and task-environment alignment, but the environment is not tied to any real project, so its realism depends entirely on the generator, which tends to produce small and tidy workspaces rather than real code. Across these routes, environment construction either starts from an existing environment or is coupled to a newly generated task from scratch. Trajectories, as observations of the environments they ran in, remain largely underexplored as a resource. The tool calls recorded inside a trajectory already reveal the content and structure of the environment it ran in. For instance, the tool Read shows file contents, and Write and Edit show how the workspace changed. This is enough to rebuild an executable copy of the original workspace. Therefore, we propose Terminal-Universe (Figure 1), a framework which turns each trajectory into a reusable environment and explores it for synthesizing new tasks and continued interactions. Specifically, to construct the environments based on the trajectories (§ 3.1), we first replay the recorded file operations and restore each file to its state before the agent changed it, holding back the agent’s own edits so that the workspace starts unsolved. Since replay usually yields only a partial workspace, a completion agent then automatically supplies the missing files and dependencies the task needs, without leaking the solution. For the corresponding tasks, we both reconstruct the original intent queries and synthesize entirely new ones. Besides, to better match real-world software engineering scenarios, we also scale the tasks on the environment along two complementary axes: breadth and depth (§ 3.2). Breadth expansion goes beyond the single-repository setting that most task synthesis assumes. We identify dependency relations between related environments and build cross-workspace tasks that span multiple codebases which are much harder, e.g., reading a reference implementation, moving a feature from one project to another, or connecting two components. Depth expansion turns a single-round task into a multi-round one. After the agent completes an initial query, a user agent asks grounded follow-ups as the workspace changes—extending it with new requirements, or, when a round fails, asking for a fix based on what went wrong. We verify every round, and the outcome is fed back to the agent as natural, user-visible feedback. Every new task comes with a verifier written by an agent inside the container, and we keep only the trajectories whose tests all pass (§ 4). On publicly available terminal agent trajectories, this pipeline produces 37.3k task-sufficient environments. Over these environments, we generate new queries and use Qwen3.7-Max as the teacher to roll out a solution trajectory for each task. Training Qwen3.5-27B on the resulting data validates the effectiveness of our method: it improves the single-round benchmark Terminal-Bench 2.1 by 11.9 points and the multi-round benchmark EvoCode-Bench v2 MT@4 by 13.8 points (§ 5). Extensive ablations confirm that each component contributes, most notably that re-solving tasks in reconstructed environments far outperforms imitating the raw trajectories.

2

Table 1: Comparison of representative environment and training-data construction methods. Strategy summarizes the primary mechanism used to construct environments or training tasks. Env. counts reusable source repositories/workspaces or independently constructed environments, and Tasks gives the reported task or training-instance count. Verif. indicates an executable task verifier, Multi-Round denotes extended multi-round queries, and Cross-WS cross-workspace synthesis. Method

Strategy

Env. Tasks Verif. Multi-Round Cross-WS

Endless Term. (Gandhi et al., 2026) TMax (Ivison et al., 2026) CLI-Gym (Lin et al., 2026) CLI-Universe (Hua et al., 2026) SkillSynth (Fan et al., 2026) OpenThinker-Agent (Raoof et al., 2026) RST (Li et al., 2026b) CalibForge (Meng et al., 2026)

task-conditioned combinatorial sampling env. perturbation taxonomy-guided skill graph-guided multi-source curation recursive evolution adversarial calibration

3,255 14.6k 29 6k 3,560 – 37.5k 5,431

3,255 14.6k 1,655 6k 3,560 100k 37.5k 5,431

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗

✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗

Terminal-Universe (ours)

trajectory reconstruction 37.3k 32.0k

✓

✓

✓

To sum up, we make the following contributions: • Environments reconstruction. We reframe recorded agent trajectories as a source of reusable executable environments, and reconstruct each one through deterministic replay followed by agentic completion—without needing the original repository or building from scratch. • Re-querying methods. We scale the utility of each reconstructed environment through new task generation. Besides the vanilla single-workspace and single-turn tasks, we contribute breadth expansion via cross-workspace task synthesis and depth expansion via multi-round user queries. Each task is paired with an agent-authored verifier, and only trajectories that pass are kept. • Empirical validation. Fine-tuning Qwen3.5-27B on the resulting corpus improves Terminal-Bench 2.1 by 11.9 points and EvoCode-Bench v2 MT@4 by 13.8 points over the same base model. Ablations confirm that each component contributes, and notably that re-solving in reconstructed environments far outperforms imitating the raw trajectories.

2

Related Work

Environment scaling for terminal agents. Existing methods scale executable workspaces through three main routes: recovering repository states from real development histories, modifying functioning workspaces, or constructing task-specific environments from generated specifications. SWE-Gym (Pan et al., 2024) and R2E-Gym (Jain et al., 2025) construct environments from repository versions associated with historical issues or commits. SWE-smith (Yang et al., 2025) and CLI-Gym (Lin et al., 2026) start from working repositories or CLI workspaces and introduce bugs or failures into them. SETA (Shen et al., 2026b) instead scales verifiable terminal environments for reinforcement learning through synthesis and adaptive environment evolution. A separate family jointly generates terminal tasks and their containerized execution environments; we discuss their task-construction strategies below. TerminalUniverse instead takes recorded agent trajectories as its starting point. It replays the file operations recorded in each trajectory and uses agentic completion to restore missing project context, producing executable workspaces that can be reused. Terminal task synthesis. Existing methods derive tasks either from abstract priors or concrete executable environments. Top-down pipelines generate task-environment pairs from categories or seeds (Gandhi et al., 2026; Pi et al., 2026; Zhu et al., 2026), while more structured variants organize generation around capability taxonomies, compositional axes, or skill graphs (Hua et al., 2026; Ivison et al., 2026; Fan et al., 2026). Other methods use agent skills, executable meta-tasks, or solver feedback to diversify and calibrate the generated tasks (Cheng et al., 2026; Pan et al., 2026; Meng et al., 2026). Environment-grounded methods instead derive tasks from working code and project context. They perturb healthy environments, mine repository documentation, ground tasks in real issues, or jointly realize instructions, solutions, and verifiers in a shared environment (Lin et al., 2026; Wu et al., 2026a; Yang et al., 2026; Shi et al., 2026). RST recursively expands verified seeds by lengthening solutions and realigning their tasks, verifiers, and environments (Li et al., 2026b). Terminal-Universe takes past agent trajectories as its starting point: it reconstructs their workspaces before generating new tasks within or across them. 3

Interactive and multi-round agents. Moving beyond isolated, single-turn prompts, recent benchmarks model agent interaction as dynamic, multi-turn dialogues. InterCode formalizes interactive coding via execution feedback in containerized shells (Yang et al., 2023). SWE-INTERACT (Raghavendra et al., 2026) uses a simulated user to progressively reveal requirements and provide targeted revisions, while SWETogether (Wu et al., 2026b) replays real user–agent sessions through a state-conditional user simulator that provides feedback as an evaluated agent progresses. ICAE-Bench (Peng et al., 2026b) evaluates interactive project construction from incomplete product requirements using an automated user agent. In persistent workspaces, EvoCode-Bench v2 (Shen et al., 2026a) evaluates agents across sequential development requests. Terminal-Universe embraces this interactive setting through depth expansion, extending reconstructed workspaces into multi-round sessions that capture iterative user feedback and requirement refinement. Table 1 positions Terminal-Universe against representative methods. In contrast to prior work, it builds its environments from recorded trajectories and scales tasks along both breadth (cross-workspace synthesis) and depth (multi-round queries).

3

Terminal-Universe

Figure 2 details the mechanisms across environment reconstruction, the four re-querying variants, and verification. The following subsections describe environment reconstruction (§ 3.1), re-querying (§ 3.2), and verification (§ 3.3), respectively. 3.1

Environment Reconstruction

b From the file and command operations recorded in a trajectory τ, we recover an executable workspace E that approximates the environment E in which τ was produced. This recovery is inherently lossy, since unaccessed files, implicit system dependencies, and external network resources leave no direct trace. We therefore reconstruct in three stages: deterministic replay recovers the file states τ exposes directly, agentic completion supplies the latent context it omits, and environment filtering keeps only workspaces sufficient for the recovered task q. Stage 1: deterministic replay. Replay processes the read, write, and edit operations in τ in chronological order to recover, for each accessed path, the earliest and latest file contents visible in the trajectory. The b0 collects each pre-existing file at its earliest observed version, before reconstructed initial workspace E the agent’s first change; files created by the agent are excluded, and the agent’s file changes are recorded separately for later verification. Since the trajectory exposes only the paths the agent touched, and file contents may be incomplete when the trajectory shows only part of a file or terminal output is truncated, b0 remains a partial workspace. E b0 and the recovered task q, a completion Stage 2: agentic completion. Given the partial workspace E agent creates missing files, completes partial files, and restores dependencies needed to make q solvable b We apply this stage to all without implementing it. We denote the resulting completed workspace by E. replayed workspaces, and its effect on workspace complexity is detailed in § 4. Stage 3: environment filtering. A completed workspace is useful only when it exposes enough project b with read-only shell and file tools and, context to support its task. An agentic judge inspects each E conditioned on the recovered task q, labels the workspace sufficient or insufficient according to whether its source, configuration, data, and structure give a capable agent enough context to work on the task (§ B.3). Only sufficient workspaces are retained for downstream task generation, and the per-stage sufficiency rates and final counts are reported in § 4. Each reconstructed workspace runs in a standardized ubuntu:24.04 container with network access. Compared with repository-specific images, this design lowers cost and simplifies deployment, with a modest reduction in resolve rate reported by prior work (Zeng et al., 2026). 3.2

Re-querying

While reconstruction yields executable environments, re-querying dictates how effectively their latent capability space is exploited. We introduce four complementary re-querying mechanisms, denoted throughout the paper as Intent Recovery, Single-WS, Cross-WS, and Multi-Round. Intent Recovery reconstructs source tasks, while Single-WS synthesizes new tasks within individual workspaces. CrossWS provides breadth by connecting related workspaces, and Multi-Round provides depth by extending an initial query into an interactive session.

4

1

Environment Reconstruction agent trajectory

read config/config.json read data/input/sample*.txt write config/settings.yaml write build/linux_build.sh write process_data.py exec ./build && pytest write test_report.json

Stage 1: deterministic replay Replayed workspace Ê0 /app

2

Re-querying Methods Intent recovery Single-workspace fix pyproject.toml packaging

/app src/

explore

scripts/

agent

novel query candidates

repair invalid PEP dependency strengthen scripts/validate.py

schemas/

build/ linux_build.sh config/ config.json data/ input/sample1-3.txt process_data.py test_report.json

Stage 2: agentic completion Completed workspace Ê /app replayed

Cross-workspace 1 workspace profiling

2 relation mining

domain language frameworks capabilities summary ...

unrelated

E

3

B similar

A

complementary

C dependency

+ schemas

D

cross-workspace task

create config/package.json in the repo A as the publishable package. Use the B's /api/package.json to model dist-based conditional exports...

+ scripts/ + src/ + Makefile

Multi-Round

+ pyproject.toml

Stage3: Environment Filter

initial query

add RFC 3339 date-time checks to the validator.

agent solves

Task-sufficient workspaces

no, cache parsed schemas must be threadsafe.

schemas go stale after edits. fix invalidation.

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.

Intent recovery. Consolidate one or more source user requests into a self-contained task. We normalize each source trajectory into a chronological stream of user requests, agent actions, and file changes. For a single-round trajectory, the sole substantive user request directly defines the task. For a multi-round trajectory, the first substantive user request establishes the task topic, while later requests are incorporated when they clarify, constrain, or extend the same task; unrelated task shifts are excluded. We use agent actions and file evidence to interpret the requests, but retain only requirements stated by the user (§ C.1). Single-workspace synthesis. Derive new queries from individual reconstructed workspaces. An offline generator inspects each workspace and synthesizes five self-contained candidate tasks under groundedness, structural diversity, and verifiability constraints. We randomly select one valid candidate per environment for rollout and verification. Breadth expansion. Connect related workspaces in a single query. Cross-workspace synthesis. To synthesize tasks spanning multiple codebases, we discover directional dependency relationships across recovered environments. An agent first profiles each workspace’s technical domain and implemented capabilities. We then retrieve candidate pairs via TF-IDF nearestneighbor search, and employ an LLM judge to identify directional dependency edges where a target workspace lacks a capability already implemented in a reference workspace. We allocate exactly one task per pair. Each cross-workspace task pairs a writable target workspace with a read-only reference workspace mounted at a separate path. The task generator confirms that the

5

functional gap is genuine and specifies observable behaviors in the target that bridge this gap, verifiable via deterministic local commands. The query provides only these target behaviors and the reference’s mount path, not its internal details, keeping the reference a genuine dependency. The solver must therefore navigate, internalize, and adapt the reference implementation on its own. Depth expansion. Extend solved terminal tasks through user-agent follow-ups. Multi-round user queries. Beginning with an initial terminal query, we preserve the workspace across coding rounds and introduce a user agent after the initial response. The continuation process employs two coordinated mechanisms to ensure coherent and realistic multi-turn trajectories: 1. Evolving task specification. The user agent maintains an explicit requirement tracker logging active, satisfied, and updated requirements. Prior to each follow-up, it updates this tracker by adding, modifying, or replacing constraints, maintaining contextual coherence as the workspace evolves. 2. Round-level verification and feedback. At each extension round, the user agent commits the updated specification, prompting an automated verifier to author round-level acceptance tests before the coding agent acts. Upon receiving the agent’s response, the test runner evaluates both new criteria and active regression checks. The solver agent is strictly isolated from test scripts and tracebacks; the user agent interprets the structured test results and translates any failure into natural, user-observable complaints. Intermediate failures are retained within the conversation history, providing realistic supervision for error diagnosis and recovery. Across rounds, the user agent’s requests fall into three interaction styles: (i) feature extension, which introduces new grounded requirements following successful verification; (ii) feature revision, triggered by test failures to demand bug fixes based on observed behavior; and (iii) feature conflict, which modifies or overrides prior specifications to reflect changing user intent. The style of each request follows naturally from the round outcome and the session context, and the resulting distribution is reported as observed (§ E.3, Table 17). Sessions continue for up to six follow-up rounds or until a termination sentinel is emitted. Figure 3 reports pass/fail patterns for the continuation data after the round-level selection of § 3.3: the 3,079 retained records average 4.51 rounds, and 69.6% contain a failure that the session subsequently repairs, preserving recovery supervision. 3.3

5.3%

23.6%

14.0%

4,563 generated sessions

9.7%

47.4%

All rounds pass One failure episode, recovered Multiple failure episodes, recovered Trailing failures, kept (≥ 2 passing rounds) Trailing failures, discarded (< 2 passing rounds)

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

Verification and Filtering

Agentic verifier construction. Each Single-WS or Cross-WS task is paired with an executable verifier authored by a dedicated agent within the target container. Conditioning on the task specification and workspace files, the verifier agent crafts a self-contained pytest suite through iterative local execution, strictly evaluating the public interfaces and expected behaviors specified in the prompt (§ D). Solution rollout. Candidate solutions are rolled out using the teacher model1 within the Claude Code scaffold (Anthropic, 2026) inside the task container. Rollouts decode with temperature 1.0, top-p = 0.95, and interleaved thinking over a 256k-token context window, with turn responses capped at 65,536 tokens, proactive summarization triggered at 176k tokens, and a maximum of 500 agent turns under a four-hour wall-clock timeout. The task environment provides containerized network access to fetch absent dependencies (§ 3.1). Verification and data selection. For Single-WS and Cross-WS, the authored test suite runs against the final workspace state after rollout, and a trajectory is accepted only if all tests pass. Multi-Round is selected at the round level instead: we trim trailing suffixes of consecutive failed rounds from terminated sessions and retain a session only if it contains at least two verified passing rounds. Intermediate failures that precede a successful recovery are kept, supplying supervision for error diagnosis and recovery. Accepted 1All model-driven components in this work use Qwen3.7-Max (xhigh effort) as the teacher model.

6

trajectories are formatted into multi-turn SFT demonstrations and undergo strict decontamination against evaluation benchmarks (§ 5). To provide concrete intuitions for the mechanisms above, we detail several comprehensive case studies in the Appendix. § E.1 traces a trajectory-to-query example, § E.2 follows a cross-workspace repository set from candidate sourcing to a selected task, and § E.3 follows a multi-round continuation from verifierdriven revision to controlled requirement change (Figure 8). § 4 reports dataset sizes, and § F reports interaction statistics.

4

Data Construction at Scale

4.1

Seed Selection

We source raw agent trajectories from diverse terminal-style CLI and software-engineering corpora. An execution trace is retained as a viable seed if the workspace state observed at its end contains at least 5 files and 100 lines. To prevent data leakage, we strictly filter out all Terminal-Bench-derived sources. Complete source breakdowns and selection statistics are detailed in § A. 4.2

Reconstruction Statistics

From the source trajectory pool, the reconstruction pipeline yields 68,263 reconstructed environments. As illustrated in Figure 4, replayed terminal workspaces initially contain few files because solution files generated during the original rollout are withheld. Agentic completion substantially enriches these environments, increasing the mean file count from 2.9 to 22.4. While SWE seeds originate from richer repository states, completion similarly expands their contextual breadth (full complexity distributions appear in Table 13). Files per workspace 22.4

2.9

Text lines (all files) 5,761

90

Terminal

Terminal x64.0

37.9

SWE

x11.7

6,622

595

SWE

6,302

487

SWE

x6.8

20

503

43

Terminal

x7.7

5.6

0

Code lines (source files)

x11.1

40

0

2500

Replayed E^0

x12.9

5000

7500

0

2500

5000

7500

Completed E^

Figure 4: Mean workspace size before and after agentic completion. After contamination filtering and repository-level deduplication, we apply the Stage 3 sufficiency judge (§ 3.1) to the surviving completed environments. Table 2: Workspace sufficiency under recovered intents. Pool Terminal SWE

Sufficient (%)

# Environments 38,294 1,900

Post-replay

Post-completion

40.2 20.1

93.5 77.1

As shown in Table 2, deterministic replay alone yields a sufficiency rate of 40.2% for Terminal and 20.1% for SWE workspaces. Agentic completion significantly improves this coverage to 93.5% and 77.1%, respectively, across 38,294 evaluated terminal environments and 1,900 SWE repositories (one representative reconstruction each) after repository-level deduplication. In total, task-grounded assessment identifies 37,273 fully sufficient environments suitable for downstream task generation (§ A). Figure 5 illustrates the diversity of the reconstructed terminal pool: Python represents the dominant primary language (84.7%), alongside C++ and C, with data processing, DevOps, and security workloads collectively accounting for over 80% of technical domains. 7

(a) Primary language

(b) Domain 84.7%

Python 7.1%

C++

47.4%

Data processing 18.9%

DevOps

C

3.1%

Security

Shell

2.0%

CLI tools

6.0%

JSON 0.8%

Infrastructure

4.9%

JavaScript 0.8%

ML / AI

4.7%

Other 1.6%

Other

3.7%

0

25

50

75

14.6%

0

10

20

30

40

50

Figure 5: Language and domain composition of reconstructed terminal workspaces. 4.3

SFT Corpus Composition

These task-sufficient environments serve as the foundation for our four re-querying variants: Intent Recovery reconstructs the original tasks, Single-WS yields novel within-repository tasks, Cross-WS discovers inter-repository dependency challenges, and Multi-Round extends initial queries into iterative sessions. Across the terminal pool, verifier-filtered Single-WS, Cross-WS, and Multi-Round synthesis yields 31,977 SFT demonstrations (25,386 Single-WS, 3,512 Cross-WS, and 3,079 Multi-Round trajectories), totaling approximately 1.42B training tokens. Median interaction statistics are provided in § F.

5

Experiments

5.1

Setup

Training. We fine-tune Qwen3.5-27B by SFT on Terminal-Universe data for two epochs. We use a constant learning rate of 7 × 10−6 , a global batch size of 256, and a 256k-token sequence length. Before training, we run a 13-gram contamination check against Terminal-Bench tasks and exclude Terminal-Bench-derived source datasets from all four re-querying variants. Single-round evaluation (Terminal-Bench 2.0 and 2.1). We evaluate Terminal-Bench with Claude Code (version 2.1.126) and Terminus2 (Merrill et al., 2026) using the XML parser. Evaluation mirrors the decoding and execution configurations of the solution rollout (§ 3.3), employing temperature 1.0, topp = 0.95, interleaved thinking, a 256k context window, a 65,536-token turn limit, proactive summarization at 176k tokens, up to 500 agent turns, and a four-hour wall-clock timeout. For Claude Code, interactive and web-retrieval tools (WebFetch, WebSearch, AskUserQuestion, EnterPlanMode, ExitPlanMode) are disabled. Each container runs with 12 CPU cores and 32 GiB of memory. Reported scores represent mean pass rates over six independent runs. Differences between Terminal-Bench 2.0 and 2.1 are documented in the benchmark update.2 Multi-round evaluation (EvoCode-Bench v2). We evaluate depth expansion on EvoCode-Bench v23 (Shen et al., 2026a), which contains 26 coding tasks and 227 rounds (5–15 requests per task). Workspaces and sessions persist, and cumulative verifiers check both current and active prior requirements. Our Qwen3.527B checkpoints use Terminus2-XML at temperature 1.0 with interleaved thinking, a 256k-token context, a per-turn limit of 65,536 tokens, proactive summarization at 176k tokens, up to 500 agent turns per request round, and a total wall-clock limit of 10 hours per stateful task. Each task is evaluated in four independent runs. MT@4 uses fail-stop scoring: a run receives credit only for the consecutive rounds it passes before its first failure, and each task-round is credited if any run reaches it successfully. The score averages credited rounds within each task and then across tasks. Case score averages verifier-case pass rates within tasks and then across tasks and runs to measure partial progress. 5.2

Main Results

Table 3 reports single- and multi-round performance. Fine-tuning Qwen3.5-27B on the Full Mixture (the verifier-filtered Single-WS, Cross-WS, and Multi-Round trajectories, 32.0k records) reaches 52.8% on 2 https://github.com/harbor-framework/terminal-bench-2/pull/53 3 https://unipat.ai/benchmarks/EvoCode-Bench

8

Terminal-Bench 2.0 and 58.1% on Terminal-Bench 2.1 (+11.2 and +11.9 over base, respectively) under Terminus2-XML. Under Claude Code, it reaches 58.2% on Terminal-Bench 2.1 (+10.4 over base). Table 3: Terminal-Bench and EvoCode-Bench v2 results (%). Terminal-Bench columns report Avg. Pass@1. Green bold marks the best score among task synthesis methods, blue underline the second best. ∗ marks scores we measure on the released models under the configurations in § G; other scores are taken from the corresponding reports. Model

Base Model

Base and teacher models Qwen3.5-27B Qwen3.7-Max Terminal task synthesis methods TerminalTraj-32B (Wu et al., 2026a) TermiGen-32B (Zhu et al., 2026) LiberCoder-235B (Lin et al., 2026) Nemotron-Terminal-32B (Pi et al., 2026) SkillSynth-32B (Fan et al., 2026) Terminal-World-32B (Cheng et al., 2026) Terminal-Lego-32B (Yang et al., 2026) CLI-Universe-32B (Hua et al., 2026) TMax-27B (Ivison et al., 2026) OpenThinker-Agent-32B (Raoof et al., 2026) Meta-Task-32B (Pan et al., 2026) RST-27B (Li et al., 2026b) CalibForge-35B-A3B (Meng et al., 2026) FACET-Terminal-27B (Shi et al., 2026)

Data size

TB Scaffold

Terminal-Bench EvoCode-Bench v2 TB2.0

TB2.1

MT@4 Case Score

– –

– –

Terminus2 Terminus2

41.6 69.7

46.2 74.5

6.3∗ 39.8∗

67.8∗ 83.4∗

Qwen2.5-Coder-32B Qwen2.5-Coder-32B Qwen3-235B-A22B Qwen3-32B Qwen3-32B Qwen3-32B Qwen3-32B Qwen3-32B Qwen3.6-27B Qwen3-32B Qwen3-32B Qwen3.5-27B Qwen3.5-35B-A3B Qwen3.5-27B

50.7k 3.3k 48.3k 490k 10.7k 5.7k 15.3k 6k 14.6k 100k 3.2k 37.5k 5.4k 1.2k

Terminus2 BashAgent OpenHands Terminus2 Terminus2 Terminus2 Terminus2 Terminus2 Vanillux2Agent Terminus2 Terminus2 Terminus2 CalibForge-Eval Terminus2

22.0 19.3 31.0 27.4 29.6 31.5 24.3 33.4 42.7 26.2 31.8 49.4 47.6 –

28.5∗ 21.3∗ – 27.9∗ – – – – 44.9 30.7∗ – – – 47.6

0.0∗ 0.0∗ – 0.0∗ – – – – 17.1∗ 0.0∗ – – – –

15.9∗ 12.2∗ – 13.7∗ – – – – 72.5∗ 19.7∗ – – – –

Qwen3.5-27B

32.0k

Terminus2

52.8

58.1

20.1

76.1

Terminal-Universe-27B

On EvoCode-Bench v2, the Full Mixture raises MT@4 from 6.3 to 20.1 and Case score from 67.8 to 76.1, showing that Full Mixture training also improves performance on persistent tasks with cumulative requirements.

6

Analysis and Ablation Studies

Our method makes multiple design choices, and this section isolates the contribution of each. We ask: (1) is reconstructing an environment and re-solving it actually better than training on the original trajectory (§ 6.1)? (2) does agentic completion matter, or is deterministic replay enough (§ 6.2)? (3) is verifier filtering worth the data it discards (§ 6.3)? and (4) how should a fixed budget be spent across the re-querying axes—breadth (§ 6.4), depth (§ 6.5), and more environments versus more queries (§ 6.6)? We finally test whether the pipeline transfers beyond terminal workspaces (§ 6.7). 6.1

Task Re-solving

This ablation asks whether reconstruction is needed at all: is re-solving a recovered task better than simply imitating the original trajectory? Table 4 compares the two on Terminal-Bench 2.1. To keep the comparison clean, Intent Recovery is not verifier-filtered, so verifier selection plays no role here. Table 4: Terminal-Bench 2.1 comparison of source-trajectory SFT and Intent Recovery (%). Variant

Data size Claude Code Terminus2-XML Avg.

Qwen3.5-27B Source trajectories

35.8k

47.82.0 33.03.9

46.23.9 40.32.1

47.0 36.7

Intent Recovery

35.8k

51.33.1

52.91.4

52.1

Re-solving improves over source-trajectory SFT. Source trajectories and Intent Recovery use the same Qwen3.5 chat template and tool-call schema for SFT. Source SFT preserves the original agents’ behavior, whereas Intent Recovery uses a stronger teacher to re-solve recovered tasks in reconstructed workspaces.

9

Source SFT averages 36.7, compared with 52.1 for Intent Recovery, suggesting that regenerating demonstrations under a consistent teacher policy provides more effective supervision. 6.2

Impact of Agentic Completion

This ablation asks whether agentic completion earns its cost, or whether deterministic replay alone is enough. We isolate the second reconstruction stage by training on Intent Recovery corpora whose environments are reconstructed with replay only, without completion. The replay-only variant trains on the 35,809 source instances that deterministic replay reconstructs, and the completed variant is the production Intent Recovery corpus at the same volume. Both share the recovered queries and teacher configuration and differ only in the environment reconstruction mode. Table 5: Effect of agentic completion on Intent Recovery. Variant Qwen3.5-27B Replay only Replay + agentic completion

Records

Terminus2-XML

–

46.23.9

35.8k 35.8k

48.73.5 52.91.4

Agentic completion helps. At closely matched training volume, training on completed environments outperforms training on replay-only environments by 4.2 points (52.9 versus 48.7) and is more stable across runs (±1.4 versus ±3.5). This is consistent with the sufficiency results in Table 2: replay alone leaves most terminal workspaces task-insufficient, and completion restores the execution context that re-solving depends on. Replay-only supervision still improves over the base model. The replay-only variant still gains 2.5 points over the base model (46.2 to 48.7). Inspecting its rollouts reveals that, when presented with an incomplete workspace, the teacher often repairs missing files or setup before addressing the task. These trajectories remain useful, but some of the supervision focuses on repairing the workspace rather than solving the recovered task. 6.3

Role of Verifier Filtering

This ablation asks whether discarding verifier-failed trajectories is worth the data it removes. For each synthesis method, we compare training on all teacher trajectories against training only on the verifier-passed subset from the same launched-task pool. Table 6: Effect of verifier filtering on Single-WS and Cross-WS. Variant

Records

Terminus2-XML

Single-WS w/o verifier Single-WS w/ verifier

35.1k 25.4k

56.03.3 56.42.6

Cross-WS w/o verifier Cross-WS w/ verifier

7.1k 3.5k

53.22.1 55.42.7

Verifier filtering matters more for harder tasks. For each synthesis method, we compare all teacher trajectories with the verifier-passed subset from the same launched-task pool. On Single-WS data, the verifier-passed subset performs similarly to the full corpus (56.4 versus 56.0) with fewer records. On Cross-WS data, retaining verifier-failed trajectories lowers performance to 53.2, whereas the verifierpassed subset reaches 55.4 with less than half the data. The effect is also visible in Multi-Round synthesis: removing round-level verifier supervision lowers both EvoCode-Bench metrics (Table 9). 6.4

Breadth Expansion

This ablation asks whether cross-workspace tasks add supervision beyond single-workspace synthesis. Table 7 evaluates Cross-WS against the Single-WS baseline. Cross-WS alone reaches 55.4 under Terminus2XML, while adding it to Single-WS raises performance from 56.4 to 58.4. 10

Table 7: Terminal-Bench 2.1 results for Single-WS, Cross-WS, and their mixture (%). Variant Qwen3.5-27B Single-WS Cross-WS Single-WS + Cross-WS

Data size

Terminus2-XML

–

46.23.9

25.4k 3.5k 28.9k

56.42.6 55.42.7 58.42.1

Table 8: Trajectory and difficulty profiles of Single-WS and Cross-WS synthesis.

Single-WS Cross-WS

Tool calls

Turns

Variant

Tokens / record

Teacher pass@1

Median

Mean

Median

Mean

Median

Mean

14 23

15.1 25.3

20 38

21.2 39.7

30.4k 46.5k

32.9k 51.9k

72.3% 49.2%

Table 8 contrasts the two synthesis variants on the same teacher. Cross-workspace tasks yield substantially longer and more complex trajectories: 1.6× the assistant turns, 1.9× the tool calls, and 1.5× the tokens per record at the median. They are also harder for the teacher: pass@1 drops from 72.3% on single-workspace tasks to 49.2%. Grounding the requirement in a second codebase forces the agent to read and reconcile two repositories before editing, which lengthens trajectories and raises task difficulty rather than merely adding data volume. How Cross-WS expands breadth. Single-WS provides the within-workspace baseline by synthesizing one novel task from each recovered environment. Cross-WS extends beyond this setting by requiring changes in a writable workspace grounded in evidence from a related read-only workspace. This exposes domain–operation combinations absent from single-workspace tasks and requires the agent to reconcile information across codebases. Where cross-workspace data helps. Mixing singleworkspace and cross-workspace records reaches 58.42.1 under Terminus2-XML, improving over the single-workspace baseline (56.42.6 ). Figure 6 breaks this comparison down by task category. Software engineering, the largest category with 26 tasks, improves from 46.9 to 49.1, and larger gains appear in model training (+15.0) and debugging (+10.0). Three categories decline by 2.1 to 2.5 points, a range that falls within run-to-run variation for categories of at most eight tasks. The gain in this largest category, together with the aggregate improvement, suggests that cross-workspace data adds useful supervision beyond single-workspace synthesis. 6.5

-5

All categories n=89

Δ pass rate (pp) 0 5 10

15

+2.0

Model training n=4

+15.0

Debugging n=5

+10.0

Mathematics n=4

+10.0

Data science n=8

+3.8

Data processing n=4

+3.3

Software engineering n=26

+2.2

File operations n=5

+1.3

System administration n=9

0.0

Security n=8

-2.1

Machine learning n=3

-2.2

Scientific computing n=8

-2.5

Figure 6: Per-category Terminal-Bench 2.1 passrate changes when Cross-WS data is added to Single-WS training under Terminus2-XML. Singletask categories are omitted.

Multi-Round Depth Expansion

This ablation asks whether multi-round continuation data improves performance on persistent, cumulative tasks, and whether round-level verification during generation matters. We evaluate on EvoCodeBench v2. Multi-round data improves depth. Adding Multi-Round data to Single-WS raises MT@4 from 18.4 to 21.0 and Case score from 71.9 to 76.9. The higher MT@4 indicates that the model completes longer sequences of requests before its first failure, while the Case score gain shows that it passes a larger share of verifier cases across the session. Round-level verification directs effective continuation. Within the matched Single-WS + Multi-Round comparison, removing round-level verifier feedback reduces MT@4 by 2.2 points and Case score by 3.7 11

points. Inspecting the resulting trajectories reveals that, without a grounded signal of what remains incorrect, continuation becomes less directed, yielding longer yet lower-quality multi-round trajectories. Table 9: Effect of Multi-Round synthesis and round-level verification on EvoCode-Bench v2 (%). Variant

Data size

MT@4 score

Case score

25.4k 28.5k 28.5k

18.4 21.0 18.8

71.93.5 76.91.4 73.22.6

Single-WS Single-WS + Multi-Round Single-WS + Multi-Round (w/o round verifier)

6.6

Expansion-Axis Ablation

This ablation asks where a fixed data budget is best spent. Starting from a common Single-WS base pool of 17,558 environments with one query and one teacher solution each (17.6k records), we double the corpus along one axis at a time: adding a second set of environments, a second query per environment, or a second teacher solution per query. All three variants reach a matched budget of roughly 35k records and are trained and evaluated under the setup of § 5 on Terminal-Bench 2.1, so any difference reflects how the budget is allocated rather than its size. Table 10: Data-scaling ablation for Single-WS synthesis. Starting from a common base pool, the corpus is doubled through additional environments, queries per environment, or solutions per query. Variant

Envs Queries / env Solutions / query Records Terminus2-XML

Base pool

17,558

1

1

17.6k

53.24.1

Environment expansion Query expansion Solution expansion

35,116 17,558 17,558

1 2 1

1 1 2

35.1k 35.1k 35.1k

56.03.3 53.83.3 53.92.4

Under this matched budget, environment expansion produces the largest movement, from 53.2 to 56.0, while adding queries or solutions leaves the score essentially unchanged (53.8 and 53.9). The pattern is intuitive: each new environment contributes a distinct executable context, and therefore new supervision, whereas a second query or solution over the same workspace mostly repeats what the model has already seen. It is consistent with our motivation of focusing on reconstructing more environments. 6.7

Cross-domain Generalization

This ablation asks whether the pipeline helps beyond the terminal domain it was built on. We apply Intent Recovery to trajectories from software-engineering (SWE) workspaces rather than terminal ones, then fine-tune and evaluate under the setup of § 5, measuring transfer on Terminal-Bench 2.1. We use Intent Recovery alone, as the simplest re-querying variant, to keep the test clean. Table 11: Terminal-Bench 2.1 pass rates (%) after training on SWE intent-recovery trajectories. Variant Qwen3.5-27B Intent Recovery

Data size Claude Code Terminus2-XML Avg. 10.3k

47.82.0 50.60.9

46.23.9 49.41.6

47.0 50.0

Of the 1,900 SWE repositories we evaluate, 1,464 are judged task-sufficient. Because a repository may contribute multiple source tasks, these repositories yield approximately 10.3k Intent Recovery training trajectories. Training on them improves the Terminal-Bench average from 47.0 to 50.0, and both scaffolds move in the same direction (Claude Code 47.8 → 50.6, Terminus2-XML 46.2 → 49.4), so the gain is not tied to a single evaluation setup. This shows that trajectories synthesized from SWE workspaces provide supervision useful for terminal-agent behavior, not only for their own source distribution. We test the SWE-to-terminal direction here; the reverse is left to future work.

12

7

Discussion and Limitations

Scaling with richer source trajectories. While Terminal-Universe demonstrates strong effectiveness when applied to public trajectory corpora, our empirical observations on higher-quality trajectories reveal a positive correlation between the complexity of the source trajectories and that of the resulting rollouts synthesized on the reconstructed environments. Trajectories with richer operational dynamics, such as multi-file manipulations and long tool-use chains, expose broader workspace state, which in turn supports more diverse and more demanding synthesized tasks. Environment complexity can also be raised by aggregation: when multiple sessions operate on the same workspace, replaying them together merges the state exposed by each session into a single reconstruction, producing environments more complex than any single trajectory can recover. Together, these observations suggest that the framework scales naturally as advancing agent capabilities make complex trajectories increasingly easy to obtain. Limitations. Terminal-Universe also has several limitations. First, we use standard Ubuntu 24.04 containers for all workspaces rather than building tailored, repository-specific environments via automated pipelines like SWE-Factory (Guo et al., 2026) or RepoLaunch (Li et al., 2026a). As a result, edge cases requiring specialized system dependencies or complex compilation steps may exhibit reduced fidelity. Second, the domain, language, and toolchain distributions of our reconstructed workspaces are fundamentally bounded by the coverage of the collected source trajectories. Expanding beyond these distributions remains an important avenue for future work. Third, a single teacher generates tasks, solutions, and verifiers. Its capability gaps may therefore limit task coverage, while errors it makes in solutions may also be missed by its tests. Future work could use multiple teachers and an independent model for verifier construction.

8

Conclusion

In this work, we present Terminal-Universe, a trajectory-based environment and task synthesis framework that reframes recorded agent trajectories from fixed demonstrations into recoverable, reusable execution environments. Through a two-stage process of deterministic replay and agentic completion, TerminalUniverse restores latent workspace state, synthesizes new tasks within each environment, and expands them across workspaces for breadth and across rounds for depth. Empirical evaluations show that re-solving recovered tasks outperforms SFT on the source trajectories, while verifier-selected SingleWS, Cross-WS, and Multi-Round trajectories improve both single- and multi-round terminal-agent performance. Overall, our findings demonstrate that recorded trajectories can be effectively repurposed into interactive execution environments, offering a scalable paradigm for synthesizing grounded agent training data without constructing environments from scratch.

Acknowledgement We are grateful to Ye Li for contributions to the CPU-based replay framework that enables efficient environment reconstruction at scale.

References Anthropic. Claude Code overview. https://code.claude.com/docs/en/overview, 2026. Accessed 2026-07-14. Alpay Ariyak, Junda Zhang, Junxiong Wang, Shang Zhu, Federico Bianchi, Sanjana Srivastava, Ashwinee Panda, Siddhant Bharti, Chenfeng Xu, John Heo, Xiaoxia Shirley Wu, James Zhou, Percy Liang, Leon Song, Ce Zhang, Ben Athiwaratkun, Zhongzhu Zhou, and Qingyang Wu. CoderForge-Preview: SOTA open dataset for training efficient agents, February 2026. URL https://www.together.ai/blog/cod erforge-preview. Project core leads: Alpay Ariyak, Zhongzhu Zhou, and Qingyang Wu. Ibragim Badertdinov, Alexander Golubev, Maksim Nekrashevich, Anton Shevtsov, Simon Karasik, Andrei Andriushchenko, Maria Trofimova, Daria Litvintseva, and Boris Yangel. SWE-rebench: An automated pipeline for task collection and decontaminated evaluation of software engineering agents, 2025. URL https://arxiv.org/abs/2505.20411. Zihao Cheng, Hongru Wang, Zeming Liu, Xinyi Wang, Xiangrong Zhu, Yuhang Guo, Wei Lin, Jeff Z. Pan, and Yunhong Wang. Terminal-World: Scaling terminal-agent environments via agent skills, 2026. URL https://arxiv.org/abs/2605.20876.

13

Zhiyuan Fan, Tinghao Yu, Yuanjun Cai, Jiangtao Guan, Yun Yang, Dingxin Hu, Jiang Zhou, Xing Wu, Zhuo Han, Feng Zhang, and Lilin Wang. Toward scalable terminal task synthesis via skill graphs, 2026. URL https://arxiv.org/abs/2604.25727. Kanishk Gandhi, Shivam Garg, Noah D. Goodman, and Dimitris Papailiopoulos. Endless terminals: Scaling RL environments for terminal agents, 2026. URL https://arxiv.org/abs/2601.16443. Lianghong Guo, Yanlin Wang, Caihua Li, Wei Tao, Pengyu Yang, Jiachi Chen, Haoyu Song, Duyu Tang, and Zibin Zheng. SWE-Factory: Your automated factory for issue resolution training data and evaluation benchmarks, 2026. URL https://arxiv.org/abs/2506.10954. gyung. LFM2-Terminal-SFT-Processed. Hugging Face dataset, 2026. URL https://huggingface.co/d atasets/gyung/LFM2-Terminal-SFT-Processed. Accessed 2026-08-23. Zhanbo Hua, Yifan Yao, Weihao Xie, Yongchi Zhao, Minghao Liu, Ruizhi Qiu, Zhewei Huang, Zun Wang, Yiyan Ji, Yunhai Ye, Letian Zhu, Xinping Lei, Han Li, Zhiyuan Ma, Zili Wang, Zhaoxiang Zhang, and Jiaheng Liu. CLI-Universe: Towards verifiable task synthesis engine for terminal agents, 2026. URL https://arxiv.org/abs/2606.22883. Hamish Ivison, Junjie Oscar Yin, Rulin Shao, Teng Xiao, Nathan Lambert, and Hannaneh Hajishirzi. Tmax: A simple recipe for terminal agents, 2026. URL https://arxiv.org/abs/2606.23321. Naman Jain, Jaskirat Singh, Manish Shetty, Liang Zheng, Koushik Sen, and Ion Stoica. R2E-Gym: Procedural environments and hybrid verifiers for scaling open-weights SWE agents, 2025. URL https://arxiv.org/abs/2504.07164. Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. SWE-bench: Can language models resolve real-world GitHub issues? In International Conference on Learning Representations (ICLR), 2024. Kenan Li, Rongzhi Li, Linghao Zhang, Qirui Jin, Liao Zhu, Xiaosong Huang, Geng Zhang, Yikai Zhang, Shilin He, Chengxing Xie, Xin Zhang, Zijian Jin, Bowen Li, Chaoyun Zhang, Yu Kang, Yufan Huang, Elsie Nallipogu, Saravan Rajmohan, Qingwei Lin, and Dongmei Zhang. RepoLaunch: Automating build and management of code repositories across languages and platforms, 2026a. URL https: //arxiv.org/abs/2603.05026. Zhongzhi Li, Yucheng Shi, Zongxia Li, Ruhan Wang, Anhao Li, Zixun Huang, Junyao Yang, Lei Ke, Ninghao Liu, Haitao Mi, and Leowei Liang. Recursive synthesis for long-horizon terminal tasks, 2026b. URL https://arxiv.org/abs/2608.05466. Yusong Lin, Haiyang Wang, Shuzhe Wu, Lue Fan, Feiyang Pan, Sanyuan Zhao, and Dandan Tu. CLI-Gym: Scalable CLI task generation via agentic environment inversion, 2026. URL https://arxiv.org/abs/ 2602.10999. Fanzhe Meng, Guoxin Chen, Jiale Zhao, Shuang Sun, Zhiyu Lin, Wayne Xin Zhao, Ruihua Song, Ji-Rong Wen, and Kai Jia. CalibForge: Adversarial solver calibration for scaling learnable terminal tasks, 2026. URL https://arxiv.org/abs/2608.06352. Mike A. Merrill, Alexander G. Shaw, Nicholas Carlini, et al. Terminal-Bench: Benchmarking agents on hard, realistic tasks in command line interfaces. In International Conference on Learning Representations, 2026. URL https://arxiv.org/abs/2601.11868. Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, and Yizhe Zhang. Training software engineering agents and verifiers with SWE-Gym, 2024. URL https://arxiv.org/ abs/2412.21139. Zhihong Pan, Jiyuan He, Kai Zhang, Yupeng Han, Ze Liu, Yuze Zhao, Yongcong Ye, and Zhaohua Yang. Meta-Task: Turning terminal task synthesis into a terminal task for scalable agent training, 2026. URL https://arxiv.org/abs/2607.27929. Xiaoxuan Peng, Kaiqi Zhang, Xinyu Lu, Boxi Cao, Yaojie Lu, Hongyu Lin, Xianpei Han, and Le Sun. LiteCoder-Terminal: Scaling long-horizon terminal environments for learning language agents, 2026a. URL https://arxiv.org/abs/2605.29559. Zhongyuan Peng, Dan Huang, Chuyu Zhang, Caijun Xu, Changyi Xiao, Shibo Hong, David Lo, Lin Qiu, Xuezhi Cao, Jiyuan He, and Yixin Cao. ICAE-Bench: Evaluating coding agents as interactive project builders, 2026b. URL https://arxiv.org/abs/2607.21217.

14

Renjie Pi, Grace Lam, Mohammad Shoeybi, Pooya Jannaty, Bryan Catanzaro, and Wei Ping. On data engineering for scaling LLM terminal capabilities, 2026. URL https://arxiv.org/abs/2602.21193. Mohit Raghavendra, Anisha Gunjal, Aakash Sabharwal, and Yunzhong He. SWE-INTERACT: Reimagining SWE benchmarks as user-driven long-horizon coding sessions, 2026. URL https://arxiv.org/ab s/2606.30573. Negin Raoof, Richard Zhuang, Marianna Nezhurina, Etash Guha, Atula Tejaswi, et al. OpenThoughtsAgent: Data recipes for agentic models, 2026. URL https://arxiv.org/abs/2606.24855. Haiyang Shen, Xuanzhong Chen, Wendong Xu, Yun Ma, Liang Chen, and Kuan Li. EvoCode-Bench: Evaluating coding agents in multi-turn iterative interactions, 2026a. URL https://arxiv.org/abs/26 05.24110. Qijia Shen, Zhiqi Huang, Vamsidhar Kamanuru, Aznaur Aliev, Jay Rainton, Ahmed Awelkair, Zhichen Zeng, Jiajun Li, Shi Dong, Yueming Yuan, Boyuan Ma, Qizheng Zhang, Jiwei Fu, Yuzhen Mao, Wendong Fan, Ping Nie, Philip Torr, Bernard Ghanem, Changran Hu, Jonathan Lingjie Li, Urmish Thakker, and Guohao Li. SETA: Scaling environments for terminal agents, 2026b. URL https: //arxiv.org/abs/2607.10891. Kou Shi, Zun Wang, Qisheng Su, Shiting Huang, Ziao Zhang, Zhen Fang, Qingnan Ren, Jin Liu, Yu Zeng, Yiming Zhao, Lin Chen, Zehui Chen, and Feng Zhao. FACET: Preserving source intent and executable state in terminal task synthesis, 2026. URL https://arxiv.org/abs/2608.18580. Siwei Wu, Yizhi Li, Yuyang Song, Wei Zhang, Yang Wang, Riza Batista-Navarro, Xian Yang, Mingjie Tang, Bryan Dai, Jian Yang, and Chenghua Lin. Large-scale terminal agentic trajectory generation from dockerized environments, 2026a. URL https://arxiv.org/abs/2602.01244. Yifan Wu, Zhuokai Zhao, Songlin Li, Ho Hin Lee, Jiacheng Zhu, Shirley Wu, Tianhe Yu, Serena Li, Lizhu Zhang, Xiangjun Fan, and Shengzhi Li. SWE-Together: Evaluating coding agents in interactive user sessions, 2026b. URL https://arxiv.org/abs/2606.29957. John Yang, Akshara Prabhakar, Karthik Narasimhan, and Shunyu Yao. InterCode: Standardizing and benchmarking interactive coding with execution feedback, 2023. URL https://arxiv.org/abs/2306 .14898. John Yang, Kilian Lieret, Carlos E. Jimenez, Alexander Wettig, Kabir Khandpur, Yanzhe Zhang, Binyuan Hui, Ofir Press, Ludwig Schmidt, and Diyi Yang. SWE-smith: Scaling data for software engineering agents. In Advances in Neural Information Processing Systems (NeurIPS) Datasets and Benchmarks Track, 2025. URL https://arxiv.org/abs/2504.21798. Sidi Yang, Chaofan Tao, Jierun Chen, Tiezheng Yu, Ruoyu Wang, Yuxin Jiang, Yiming Du, Wendong Xu, Jing Xiong, Taiqiang Wu, Lifeng Shang, Xiaohui Li, Ngai Wong, and Haoli Bai. What makes interaction trajectories effective for training terminal agents?, 2026. URL https://arxiv.org/abs/2606.03461. Wenhao Zeng, Yuling Shi, Xiaodong Gu, Chao Hu, Chaofan Wang, Yuhao Cui, Hongting Zhou, Mengnan Qi, Jianqiao Wangni, Zhaojian Yu, Shuzheng Gao, Kai Cai, and Shilin He. Dockerless: Environment-free program verifier for coding agents, 2026. URL https://arxiv.org/abs/2606.28436. Kaijie Zhu, Yuzhou Nie, Yijiang Li, Yiming Huang, Jialian Wu, Jiang Liu, Ximeng Sun, Zhenfei Yin, Lun Wang, Zicheng Liu, Emad Barsoum, William Yang Wang, and Wenbo Guo. TermiGen: High-fidelity environment and robust trajectory synthesis for terminal agents, 2026. URL https://arxiv.org/abs/ 2602.07274.

15

Appendix A

Data Sources and Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

B

Environment Reconstruction Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

C

B.1

Reconstruction and Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

B.2

Workspace Sufficiency Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

B.3

Failure Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Re-querying Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 C.1

Intent Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

C.2

Single-WS Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

C.3

Cross-WS Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

C.4

Multi-Round User Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

D

Verifier Construction Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

E

Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 E.1

Reconstruction and Single-Workspace Re-querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

E.2

Cross-WS Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

E.3

Multi-Round User Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

F

SFT Dataset Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

G

Evaluation Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

16

A

Data Sources and Selection

Table 12 summarizes each included source before and after reconstruction. Whether a trajectory can be reconstructed depends on the file evidence it exposes: multi-file editing traces reveal enough project context to rebuild, whereas command-heavy CLI traces often expose few file contents. We exclude Terminal-Bench-derived corpora and sources dominated by view-only operations or unsupported action formats. SWE deduplication and decontamination. Public SWE corpora often contain multiple rollouts or formats of the same task. We deduplicate within each source by repository, base commit, and problem statement, selecting the trajectory whose replay exposes the most workspace content. We then remove instances from SWE-bench Verified repositories (Jimenez et al., 2024) and records that cannot be linked to a source trajectory. Table 12 gives the resulting per-source counts. Table 12: Source corpora and reconstructed environments. The Trajectories column counts source trajectories drawn from each corpus. Source corpus

Pool

SWE-rebench (Badertdinov et al., 2025) SWE-smith (Yang et al., 2025) CoderForge (Ariyak et al., 2026) SWE-Gym (Pan et al., 2024) LFM2-Terminal (gyung, 2026) LiteCoder-Terminal (Peng et al., 2026a)

License

Trajectories Environments

SWE CC-BY-4.0 SWE MIT SWE Apache-2.0 SWE MIT Terminal CC-BY-4.0 Terminal MIT

Total

67,074 95,851 32,964 4,152 139,841 19,711

6,118 8,476 3,978 929 46,037 2,725

359,593

68,263

Table 13: Workspace complexity before and after agentic completion. Cells report median / mean. Terminal pool

SWE pool

b0 ) Completed (E) b Replayed (E b0 ) Completed (E) b Replayed (E Files per workspace Text lines (all files) Code lines (source files)

2 / 2.9 60 / 90 0 / 43

13 / 22.4 539 / 5,761 316 / 503

5 / 5.6 537 / 595 421 / 487

21 / 37.9 1,854 / 6,622 1,643 / 6,302

Figure 7 summarizes the core reconstruction and sufficiency stages. TRAJECTORIES

Source trajectories 359,593

REPLAY & COMPLETION

FILTERING & DEDUPLICATION

Reconstructed environments 68,263

Retained environments 40,194

Insufficient replay complexity 291,330

SUFFICIENCY JUDGE

Task-sufficient 37,273

Task-insufficient 2,921 Contamination-filtered and repo-deduplicated 28,069

Figure 7: Core environment-reconstruction flow.

17

B

Environment Reconstruction Details

B.1

Reconstruction and Completion

Source corpora encode file operations differently, so we normalize reads, writes, and edits into an ordered event stream. We keep the observed content of read-only files and, for modified files, the content visible before the first change. These contents may be partial or truncated. Files created by the agent and all later changes are left out of the replayed workspace. The completion agent receives the recovered request, partial workspace, and file inventory. It fills missing project context by creating files, completing partial files, and configuring dependencies needed by the existing project. It must not implement the requested task or reveal where its solution should be made. Packaging. Reconstructed projects are placed under /app. Files accessed elsewhere in the filesystem are stored separately. PROMPT Environment Completion ROLE & GOAL

You are a workspace completion agent. becomes solvable, but NOT solved.

Complete a Docker workspace so that the given task

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.

Completion quality. Manual inspection of 30 randomly sampled Terminal completions found that 22 contained only task-relevant support files, while eight introduced substantial files or code not needed to support the task. We found no task solutions in the 30 completed workspaces. B.2

Workspace Sufficiency Evaluation

Evaluation scope. We evaluate every terminal reconstruction that survives decontamination and repository-level deduplication. For SWE, we evaluate one representative reconstruction and its Intent Recovery task per repository. The agentic judge inspects each workspace with read-only shell and file tools. Scoring. A workspace is task-sufficient when its source, configuration, data, and structure give a capable agent enough context to work on the task. Dependencies, caches, generated outputs, and optional documentation that can be recreated are not required. The judge evaluates available project context rather than build success. Table 14 gives the corresponding source-level breakdowns. 18

Table 14: Source breakdown of workspace sufficiency under recovered intents after agentic completion. Source Terminal pool LFM2-Terminal LiteCoder-Terminal SWE pool SWE-rebench SWE-smith CoderForge SWE-Gym

n

Sufficient

Sufficient (%)

36,204 2,090

34,467 1,342

95.2 64.2

1,734 114 47 5

1,350 85 27 2

77.9 74.6 57.4 40.0

Sufficiency rates reflect how much project context the trajectories expose. Agentic completion can add common project files around observed evidence but cannot recover unseen project-specific content. Some SWE subsets are too small for fine-grained comparison. B.3

Failure Analysis

For task-insufficient workspaces, the judge cites missing or truncated source files, task scripts, input data, configuration, and deployment files. Missing tests, manifests, or package init files usually indicate a partial source tree. Judge prompt. PROMPT Workspace Sufficiency Judge ROLE & INSTRUCTION

You are evaluating whether a reconstructed coding workspace contains enough project-specific context for the task below. The task is evidence for evaluation only. Do not solve it. RUNTIME INPUT

<task> <TASK_INSTRUCTION> </task> INSPECTION & DECISION RULES

Inspect the workspace actively and read only. The project root is /app. Also inspect task-referenced system paths when relevant. Use shell commands and file-reading tools to understand the tree, manifests, configuration, data, tests, and files named or implied by the task. Return one binary judgment: * sufficient: The workspace contains the project-specific source, configuration, data, and task context that a capable coding agent needs to make a grounded attempt. Third-party packages, build caches, generated outputs, and optional documentation may be absent when manifests or source context make them recoverable in the normal development workflow. * insufficient: Critical task-referenced files, modules, data, configuration, or project structure are absent, skeletal, or inconsistent, so an agent would need to invent or reconstruct core context before it could attempt the task. Base the label on concrete workspace evidence. Do not infer completeness from the task wording alone. Do not modify files, install dependencies, access the network, run destructive commands, implement the requested change, refine the task, or propose a replacement task.

19

PROMPT Workspace Sufficiency Judge (continued) OUTPUT CONTRACT

Return exactly one JSON object on one line: { "label": "sufficient|insufficient", "confidence": 0.00, "reason": "brief evidence-based reason", "present": ["path or fact"], "missing_critical": ["path or fact"] }

C

Re-querying Details

Across all four variants, the generated request specifies an observable goal while leaving the implementation strategy to the coding agent. Cross-workspace layout. Each Cross-WS pair is mounted as repo0 and repo1 under /app/workspaces. The generation agent chooses a writable target and a read-only reference. The coding agent sees the same layout, and the verifier checks that the reference remains unchanged (§ 3.3). Prompt presentation. The templates retain each generator’s inputs, instructions, and output schema. Repeated rules and examples are shortened. Values in angle brackets are filled at runtime. C.1

Intent Recovery

Generation mechanism. Intent Recovery receives the cleaned task, a chronological conversation trace, and file evidence. A single-round trajectory uses its sole substantive user request directly. For a multiround trajectory, the first substantive request sets the task topic; later requests are incorporated only when they clarify, constrain, or extend the same task, and unrelated task shifts are excluded. We use agent actions and file evidence to interpret the requests, but retain only requirements stated by the user. Only the generated core_objective becomes the Intent Recovery instruction; the remaining output fields are retained as metadata. PROMPT Intent Recovery ROLE & INSTRUCTION

You are a task intent reverse-engineering expert. Given a task description, conversation trace, and file evidence, infer the user's actual objective. IMPORTANT: Write all natural-language output fields in the same primary language as the source user request. Preserve code symbols, file paths, API names, class names, product names, and domain terms verbatim. RUNTIME INPUTS

## Task Description <TASK_DESCRIPTION> ## Conversation Trace <CONVERSATION_TRACE> ## File Evidence <FILE_EVIDENCE> ANALYSIS STEPS

## Analysis Steps (execute during reasoning, do not output) 1. Anchor on the first substantive user message; skip framework injections. 2. Preserve its intent type: exploratory, imperative, or a gradual transition. 3. Use later turns only for clarifications and added constraints. 4. Match the abstraction level of the user's words. Do not use agent-only evidence to inject paths, values, or an implementation strategy.

20

PROMPT Intent Recovery (continued) OUTPUT CONTRACT

Return strict JSON only: { "core_objective": "2-4 self-contained sentences", "success_criteria": ["independently verifiable functional criterion"], "specified_output_format": null, "has_examples": false, "mandatory_constraints": ["0-3 must-do constraints"], "prohibitions": ["0-3 must-not-do constraints"] } Rules: - core_objective must stand alone and preserve the main-line task. - Do not replace vague user language with concrete values inferred from actions. - Criteria describe observable outcomes, not implementation details. - Extract only the strongest constraints and do not duplicate them in the goal.

C.2

Single-WS Synthesis

Generation mechanism. Single-WS receives a path inventory and may inspect selected files with readonly commands. It cannot modify the repository, access the network, or scan outside the workspace. After parsing and deduplication, we select one grounded task per workspace. PROMPT Single-WS Synthesis ROLE & GOAL

You are a repository exploration and terminal-task synthesis agent. Inspect the private project rooted at /app and propose 5 diverse, challenging terminal tasks for future coding agents. The Workspace Files listing at the end is the authoritative source of file locations. OUTPUT CONTRACT

Output exactly one JSON array containing exactly 5 self-contained task strings. Output no markdown, comments, explanations, objects, or extra keys. EXPLORATION & TASK RULES

Exploration: - Start from the supplied inventory; inspect only targeted project files. - Prefer cheap inspection commands; do not modify repository files. - Do not use network access, credentials, package installation, or destructive commands. Do not expose secrets or proprietary code excerpts. Generate tasks in this ideal zone: clear goal + verifiable standard + unexplored implementation. Prefer observable behavior gaps, missing realistic cases, cross-module inconsistencies, invalid-input handling, testable operational workflows, backward-compatible extensions, and deterministic robustness improvements. Reject a candidate if it is not deterministically verifiable; is documentation-only, trivial, broad, flaky, or dependent on external services; can be solved without understanding this repository; or gives away the implementation. Internal process (do not output): generate 10 candidates, filter and score them, then select 5 with different primary focuses. Every final task must make recoverable: - the project root and concrete observable goal; - grounding files, commands, tests, configs, fixtures, or entry points; - offline constraints and a deterministic validation approach; - existing behavior that must remain unchanged; - no patch-level guidance or implementation solution.

21

PROMPT Single-WS Synthesis (continued) RUNTIME INPUT

## Workspace Files <WORKSPACE_FILE_INVENTORY>

C.3

Cross-WS Synthesis

Candidate sourcing. We profile each workspace, then use TF–IDF to retrieve nearby candidates within each language group. An LLM labels each pair as similar, complementary, dependency, or unrelated and identifies the side with the missing capability. We then select dependency pairs using file checks, a rule that no workspace appears in two pairs, and a limit on how often each workspace is used. Both repositories are mounted as peers, and the generation agent chooses their final roles. Task generation. A generation agent reads both repositories, assigns their roles, and returns one task, file evidence, and three hidden dependency facts. The task must depend on at least three details found only in the reference, but cannot state those details or name its internal paths. It must name the target files, define executable checks, preserve existing target behavior, leave the reference unchanged, and remain solvable offline. Pairs without a useful reference asset are rejected. Checks. We reject tasks that are malformed, that state the hidden facts, or that name internal reference paths. SFT records require a valid query, verifier, and successful teacher trajectory. PROMPT Cross-WS Workspace Profiling ROLE & EXPLORATION RULES

You are a repository analysis agent. A software project has been mounted in this container. The Docker Layout Files listing at the end gives the authoritative locations of project files; use it as the starting map. Explore the project and produce one structured intent record describing what it is and does, for matching against projects in the same domain. Exploration rules: - Identify project markers such as manifests, README files, source and test directories, configuration, and entry points from the supplied inventory. - Inspect targeted file contents with cheap read-only commands. Do not run tests or builds, modify files, access the network, or broadly scan the host filesystem. - Ground every field in code evidence. Do not expose secrets, credentials, tokens, or large verbatim excerpts. OUTPUT CONTRACT

Output exactly one JSON object and nothing else: { "domain": "one coarse domain bucket", "subdomain": "finer tag in at most 4 words", "primary_language": "dominant programming language", "frameworks": ["frameworks, libraries, and datastores defining the stack"], "core_capabilities": ["3-8 short verb phrases"], "key_entities": ["core modules, data models, and domain objects"], "summary": "detailed, self-contained, code-grounded description" } The summary should cover purpose, domain, stack, architecture, main components, data flow, entities and relationships, algorithms, integrations, external interfaces, and extension-relevant details. Avoid generic filler or unsupported capabilities. RUNTIME INPUT

## Docker Layout Files <DOCKER_LAYOUT_FILES>

22

PROMPT Cross-WS Relation Judging RELATION & TASK RULES

Classify the relationship between an ANCHOR coding workspace and each candidate: - similar: same domain and essentially the same capabilities; parallel implementations of the same thing. - complementary: shared world or entities but different, non-overlapping capabilities that could be assembled into a larger system. - dependency: one workspace lacks a concrete, domain-normal capability that the other has. Set donor to the side that has it. - unrelated: no meaningful cross-workspace task. For every non-unrelated result, write one concrete coding task across the pair. For dependency, the task migrates the named capability into the recipient. OUTPUT CONTRACT

Return only one JSON array in candidate order: [ { "i": <CANDIDATE_INDEX>, "relation": "similar|complementary|dependency|unrelated", "donor": "anchor|candidate|null", "capability": "<CAPABILITY_OR_NULL>", "task": "<ONE_LINE_TASK_OR_NULL>" } ] RUNTIME INPUTS

ANCHOR: <ANCHOR_PROFILE> CANDIDATES: <NUMBERED_CANDIDATE_PROFILES> PROMPT Cross-WS Dependency-Gap Task Synthesis ROLE & GOAL

You are a repository exploration and cross-repository task synthesis agent, responsible for designing high-quality coding tasks for other solvers. You will be given two peer software repositories mounted under /app/workspaces (repo0 and repo1). One will become the target repository (the repository the solver will modify), and the other will become the reference repository (read-only, providing specifications, constraints, or data). Your job: explore both repositories, decide the role direction, and generate exactly one coding task. Important context: The reference repository may not contain a complete implementation. However, it may provide interface contracts, configuration schemas, test fixtures, sample outputs, algorithm descriptions, or documentation. These assets are all real and usable, and serve as the source of task constraints. EXPLORATION & DIRECTION

1. Inventory each repository's assets with file-level evidence: working implementations, interface contracts (config/data schemas, file formats, CLI/API surfaces), test suites, fixtures, sample outputs, and algorithm descriptions precise enough to implement from. Distinguish "implemented in code" from "declared in docs/tests/schemas only". 2. Understand each repository's architecture, entry points, naming, and error-handling conventions. 3. Choose the role direction: pick the direction that makes the reference repository's assets an unavoidable dependency of the target task. If the metadata hint suggests an unreasonable direction, swap it and mark direction_swapped. 4. Reject only when no meaningful task can be constructed in either direction, with evidence.

23

PROMPT Cross-WS Dependency-Gap Task Synthesis (continued) TASK RULES

1. Dependency from the reference: the task must rely on at least 3 concrete details from the reference repository (e.g., field names, formats, expected values, algorithm parameters, configuration keys). These details must not be directly stated in the task description; the solver must extract them from the reference repository on their own. 2. Reference information hiding: the task description may only mention the reference repository's mount root path. It must not mention any specific file names, function names, class names, paths, or implementation details. 3. Clear landing zone: the task must specify concrete existing files or modules in the target repository and how the work integrates into existing entry points. Target repository paths are allowed and required. 4. Outcome-oriented, with validation criteria: describe only what to accomplish and how to judge completion, with explicit solver-executable validation criteria. Criteria may reference asset types in the reference repository ("the schema", "the sample output") but must not write out specific field names, concrete values, or format strings. 5. Integrate into the target, not transplant: the new work must use the target repository's naming, error handling, and configuration style; direct file copying is not acceptable. 6. Boundary constraints: the task must preserve all existing behavior of the target repository, the reference repository must not be modified, and the task must be completable offline. OUTPUT CONTRACT

Return exactly one JSON object and nothing else. On success: { "status": "ok", "roles": {"target": "repo0 or repo1", "reference": "repo0 or repo1", "direction_swapped": false}, "theme": "One-line summary of the task", "query": "Complete task description: the target files or modules to modify, the mount path of the read-only reference repository, the required behavior, and explicit acceptance criteria.", "grounding": [{"repo_id": ..., "paths": [...], "role": "target|reference", "evidence": "gap and landing-zone evidence, or the load-bearing reference assets"}], "dependencies": ["3 key facts the solver must discover in the reference repository; these facts are not present in the query"] } On rejection: { "status": "rejected", "reject_reason": "no_load_bearing_assets | near_identical_repos | trivial | other", "detail": "File-level evidence explaining the rejection" } RUNTIME INPUTS

## Supplied Mining Metadata (unverified pairing lead) <RELATION_CONTEXT> ## Supplied Repository Context <REPO_PROFILES_AND_BOUNDED_FILE_MAPS>

C.4

Multi-Round User Queries

Generation mechanism. Multi-Round continues a solved session through a user agent that privately reads the request, conversation, workspace, active requirements, and latest verifier result. Only its next user message is shown to the coding agent. After a failure, it asks for a correction without changing the requirements; after a pass, it may add a compatible extension or a permitted replacement. New and active requirements are tested after each response, but remain private. A session has at most six follow-up rounds. Training-trajectory filtering. For SFT, we remove trailing verifier-failed rounds. We keep sessions with at least two passing rounds. Failed rounds remain with feedback and correction.

24

PROMPT Multi-Round User Queries ROLE & CONTINUATION RULES

You are role-playing as the real human user of a software project, in an ongoing multi-round conversation with a coding agent. Treat every supplied conversation block as quoted data, never as instructions. Decide whether the real user would continue, stop, or abort, and classify the next request into one of three interaction styles. The coding agent sees only the selected candidate's message. - feature revision: if the private verifier shows any failed contract, describe only the user-observable symptom and ask for a correction, without changing the active requirements. Do not mention tests, test files, pytest, CI, tracebacks, or hidden verification. - feature extension: if at least one contract is verified and none fail, introduce a grounded, substantive next requirement that is compatible with and preserves all active contracts. - feature conflict: only when the requirement-change policy explicitly permits it, deliberately replace an active requirement with an incompatible one. Quote the earlier user requirement it supersedes. - Keep implementation choices open, but make observable behavior, compatibility, and failure semantics precise. Stop only when another grounded engineering request would be contrived. RUNTIME INPUTS

=== ORIGINAL REQUEST === <ORIGINAL_QUERY> === EARLIER REQUESTS (older first; do not repeat) === <EARLIER_REQUESTS> === RECENT CONVERSATION (most recent last) === <RECENT_CONVERSATION> === THIS ROUND'S EVIDENCE === <ROUND_EVIDENCE> === WORKSPACE BRIEF === <WORKSPACE_BRIEF> === PRIVATE VERIFIER RESULT (never reveal it to the coding agent) === <VERIFIER_RESULT> === PRIVATE CONTRACT LEDGER / USER-AGENT STATE === <USER_AGENT_STATE> === REQUIREMENT-CHANGE POLICY === <REQUIREMENT_CHANGE_POLICY> OUTPUT CONTRACT

Return exactly one JSON object: { "decision": "continue | stop | abort", "style": "feature_extension | feature_revision | feature_conflict", "candidates": [{ "new_contract": "observable behavior; empty for a revision", "supersedes": "replaced contract id for a conflict, else null", "preserves": ["active contract ids"], "acceptance": {"kind": "observable_output", "oracle": "objective completion condition"}, "message": "one focused, natural user request" }], "selected_candidate": 0 } For a feature revision, candidates has exactly one item that repairs the same contract and adds no new one. For stop or abort, candidates is [] and selected_candidate is null.

25

D

Verifier Construction Details

Test rules. For Single-WS and Cross-WS tasks, the verification agent sees the task specification and the initial workspace, but not the solution. It writes one self-contained pytest file using absolute paths and public interfaces. The tests must exercise the task requirements without network access and without modifying the workspace; temporary files are placed under /tmp. PROMPT Agentic Verifier Construction ROLE & INSTRUCTION

You are a verification engineer agent. A coding task (the "query") has been designed for a future solver, who will work in the repository mounted at /app. The solver has NOT started yet. Your job: produce a hidden, deterministic pytest suite that will decide, after the solver finishes, whether the solver's final workspace satisfies the query's acceptance criteria. The repository at /app is in its INITIAL state. The future solver never sees your tests. HOW TO WORK

1. Explore the repository (read files; run things where useful) to learn the EXISTING interfaces, file layout, data formats, and packaging. 2. For NEW behavior demanded by the query, take interface details from the query text. Where the query leaves a detail open, assert only what the query actually pins down; never invent stricter requirements than it states. 3. Expected values for the NEW capability must be computed independently inside the test: read input data shipped in the repository at test runtime and recompute the expected result, or take values the query itself states. NEVER derive an expectation for new behavior by running the current, incomplete implementation. For PRESERVATION tests only, the current observed behavior is the baseline. 4. For each task requirement, write 1-3 focused tests. Keep the whole suite at 18 tests or fewer. 5. Do NOT implement preservation by running the repository's own test suite; the solver may legitimately modify those files. 6. Your suite judges the RESULTING BEHAVIOR of the product code, not the solver's process. NON-NEGOTIABLE TEST RULES

- ONE self-contained file (test_outputs.py): every fixture and helper inside it; no conftest.py or sibling files. - Absolute paths only (/app/...); NEVER use __file__. - Public surfaces only: CLI invocations, produced artifacts, documented entry points, config handling. - Only import the standard library, pytest, and packages already importable (verify with `python3 -c "import X"`); verify executables with `command -v` before use. - NEVER use pytest.skip/skipif/importorskip/xfail; a missing feature must FAIL. - Deterministic; no network; no wall-clock or randomness dependence; assertions only. - Tests may READ /app freely but must never write into it; scratch files go under /tmp. MANDATORY RED CHECK

Write your suite to a scratch location and actually run it against the current, unmodified workspace. Requirements on the observed result: - At least one test that targets the missing capability must FAIL (proving the gap is real and currently open). - Zero collection errors and zero infrastructure errors; failures must come from assertions or from the expected absence of the new capability, not from a broken test file. - The preservation tests must PASS now; if one fails on the unmodified workspace, report rejection instead of shipping a broken suite. Iterate on the suite until these hold, and record the final observed pytest summary.

26

PROMPT Agentic Verifier Construction (continued) OUTPUT CONTRACT

On success: { "status": "ok", "files": {"test_outputs.py": "<the complete, final content of the pytest file>"}, "initial_run": {"passed": <int>, "failed": <int>, "errors": <int>, "summary": "..."}, "red_tests": ["names of the tests that fail on the unmodified workspace"], "coverage": [{"criterion": "...", "tests": ["test_name", "..."]}], "notes": "tolerances, determinism caveats, anything the solve-time harness should know" } On rejection: { "status": "rejected", "reject_reason": "query_unverifiable | workspace_broken | other", "detail": "2-4 sentences of file-level evidence." }

Intent Recovery. Intent Recovery is not filtered by an agentic verifier, preserving comparability with source-trajectory SFT.

E

Case Studies

E.1

Reconstruction and Single-Workspace Re-querying

We illustrate reconstruction and reuse with a TypeScript and React project (MirrorBrain). Its workspace supports several coding tasks without requiring missing source files. Table 15 summarizes the reconstruction and re-querying stages. Table 15: MirrorBrain reconstruction and re-querying trace. Stage

Observable artifact

Source trajectory

Refines React interface components and a focused test across navigation, common controls, review cards, and draft editing while preserving the existing workflows. Recovers the project manifest, test configuration, React application, Fastify service, memory-review and cache modules, integration adapters, and end-to-end fixtures. 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. Produces a cross-component interface objective covering navigation, tabs, pagination, candidate cards, and action buttons. Explores the workspace and generates tasks spanning normalization, URL classification, client errors, API schemas, and cache reconciliation.

Deterministic replay Agentic completion Intent Recovery Single-WS synthesis

Trajectory evidence. The source trajectory changes navigation, shared controls, candidate review actions, and draft views. It also tests keyboard navigation, ARIA state, loading, and disabled behavior. Replay recovers the surrounding project state; selected paths are shown below. REPLAYED

selected paths

i /app/Workspace/mirrorbrain/

|-- D package.json |-- D vitest.config.ts |-- g tests/e2e/fixtures/ | ‘– Ã mirrorbrain-mvp-fixture.ts ‘– g src/ |-- g apps/

27

| |-- g mirrorbrain-http-server/ | | |-- D index.ts | | ‘– Ã index.test.ts | ‘– g mirrorbrain-web-react/src/ | |-- D api/client.ts | |-- g components/{artifacts,common,layout,memory,review}/ | ‘– D contexts/MirrorBrainContext.tsx |-- g integrations/ | |-- g activitywatch-browser-source/{index.ts,index.test.ts} | ‘– g openviking-store/{index.ts,index.test.ts} ‘– g modules/ |-- g memory-events-cache/{index.ts,index.test.ts} ‘– g memory-review/{index.ts,index.test.ts,normalize-memory-items.ts}

Agentic completion. Replay already recovers a functional project. Completion preserves its source and tests and adds a memory event, integration adapter, React context, and runtime context. The generated package-lock.json is omitted. ADDED

selected root-filesystem paths

i /

|-- Ó .gitignore |-- g mirrorbrain/memory-events/ | ‘– D browser:101.json |-- g src/ | |-- g apps/mirrorbrain-web-react/ | | |-- Ó .gitignore | | ‘– D src/contexts/MirrorBrainContext.tsx | ‘– D integrations/openviking-store/index.ts ‘– g tmp/ |-- @ mirrorbrain-debug.log ‘– @ mirrorbrain-dev-new.log

Recovered intent. Intent Recovery uses the source trajectory, rather than the completed workspace, to recover: 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. The trajectory carries out this objective through consistent active states, focus-visible styling, keyboard navigation, ARIA semantics, loading states, and a focused component test. Generated queries. Single-WS ignores the source solution and explores only the completed workspace. Its generated requests target existing behavior and interfaces: 1. Shell-event normalization. Extend normalize-memory-items.ts so shell events already captured and rendered by the system can participate in daily review without regressing browser events. 2. URL classification. Replace substring-based development server detection with structured URL handling and distinguish GitHub Actions pages from ordinary repository pages. 3. Client error handling. Route five mutation methods in api/client.ts through consistent statusaware JSON handling, including descriptive behavior for non-JSON failures. 4. Response schema alignment. Extend the existing Fastify candidate-memory schema with role and contribution so React review components receive the required evidence metadata. 5. Cache-source reconciliation. Merge workspace and OpenViking events at cache initialization using existing ID and URL-signature deduplication, preserving reverse-chronological order. E.2

Cross-WS Synthesis

We trace Cross-WS synthesis on two C toolkits for RSA cryptography. The target provides key generation, encryption, and signing but no decryption program; the reference implements the full round trip. Relation matching therefore selects RSA decryption as the missing capability. Table 16 summarizes the synthesis stages. 28

Table 16: Synthesis trace for the RSA toolkit dependency pair. Stage and output

Evidence

Relation mining

Independently generated profiles classify both workspaces as C RSA toolkits; TF–IDF retrieval proposes the pair, and the relation judge records the directional capability gap “RSA decryption”. The target is mounted writable at /app/workspaces/repo1; the reference is mounted read-only at /app/workspaces/repo0. The generator reads the actual files of both workspaces, confirms that the capability is implemented in the reference and absent from the target, and generates a task grounded in facts found only in the reference. An in-container agent authors the test suite and executes it on the initial workspace. New-capability tests fail while the preservation tests and the reference-unchanged check pass, satisfying the red-check requirement. The teacher solves the task; all clean checks pass, and the trajectory is retained in the pass-only corpus.

Pair packaging Query generation Verifier generation Solution rollout

Mounted pair. The two toolkits share a domain but differ in completeness: read-only reference and writable target · key files i /app/workspaces/ SOLVER

|-- g repo0/ | |-- D rsa_keygen.c | |-- D rsa_encrypt.c | |-- D rsa_decrypt.c | |-- D rsa_sign.c | |-- g input/ | | ‘– @ plaintext.txt | ‘– g output/ | ‘– @ decrypted.txt ‘– g repo1/ |-- D rsa_keygen.c |-- D rsa_encrypt.c |-- D rsa_sign.c |-- g input/ | ‘– @ plaintext.txt |-- g output/ | ‘– @ decrypted.txt ‘– g task_file/ |-- g input/ | ‘– @ plaintext.txt ‘– g output/

Grounded capability gap. The target has key generation, encryption, and signing but no decryption source. Its encryptor fixes the padding mode and public-key loader, while the plaintext is the round-trip input. The reference reveals the private-key loader, decrypt call, padding mode, and hardcoded input paths. These hidden facts do not appear in the task, which names only the reference root. Selected request (abridged). The RSA cryptography toolkit at /app/workspaces/repo1 currently supports key generation, encryption, and signing, but is missing the decryption program needed to complete the encrypt/decrypt round-trip. Create a new file rsa_decrypt.c in the root of /app/workspaces/repo1 that reads an encrypted binary file and a private key, then decrypts the ciphertext back to plaintext. The program must integrate seamlessly with the existing toolkit: it should work with keys produced by the existing rsa_keygen.c and ciphertext produced by the existing rsa_encrypt.c, and it must follow the coding conventions, error-handling style, OpenSSL API usage patterns, and output path conventions already established by the other programs. A reference implementation exists at /app/workspaces/repo0: consult it to determine the exact OpenSSL API calls, padding mode, PEM reading function, file paths, command-line interface, and resource cleanup pattern required. When run after rsa_keygen and rsa_encrypt, the program must produce an output file whose contents are byte-for-byte identical to the original plaintext input.

29

What the verifier checks. The suite covers the new file, compilation, round trips, command-line behavior, input paths, padding, and OpenSSL calls. Preservation tests cover the existing programs and keep the reference unchanged. The teacher solution passes the full suite. E.3

Multi-Round User Queries

Initial query

Extension

Extension

Extension

Resumable incremental ingestion

Threshold-based alerting

Reporting and reconciliation

Configurable sensor paths tests fail; user requests a fix

tests pass; user continues

Revision

Conflict

Extension

Correct scaled, unstable aggregates

Alert snapshot → event history

Dry-run reconciliation 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.

Table 17: Distribution of interaction styles across continuation rounds in the retained Multi-Round records. We impose no target ratio over the styles. Interaction style

Share

Feature extension Feature revision Feature conflict

62.7% 29.3% 8.0%

Table 18 follows the user requests across rounds.

30

Table 18: Abridged user requests from the Multi-Round sensor-ingestion trajectory. Bracketed ellipses mark omitted text. “Revision” corrects the current requirement; “conflict” replaces it. Round

User-request excerpt

Initial request

“Working in the project root /app, the entrypoint sensor_processor.py hard-codes both its input path ... and its output path ..., which makes the script impossible to run against alternate data without editing source. Make it possible to invoke the script as python sensor_processor.py <input_csv> <output_json> so that the two positional arguments override the input and output locations.” “The path override work is solid, thanks. Now I need this to stop being a one-shot script, because in production my sensor_data.csv keeps growing and I don’t want to re-crunch the entire file every time I get a new batch of readings. [...] Please add a resumable/incremental ingestion mode backed by a small persisted state store.” “The row-counting side of the incremental mode looks right — readings_count comes out at 150 per sensor on a fresh run and rises to exactly 154 after I append four rows, so old rows aren’t being double-counted. But the actual aggregate values are wrong and unstable, and it’s making the output useless for me. [...] It looks like each reading is being scaled down before it’s aggregated.” “The aggregates are solid and stable now — thanks. The next thing I actually need for production is alerting, because right now I have to eyeball processed_results.json to notice when a sensor drifts out of its safe range. [...] Please add a threshold rules engine in a new rules.py, driven by a JSON rules config.” “The alerting engine is doing its job now, but I’ve hit a real production gap: I’ve decided to change how alerts.json works. Right now it’s overwritten every run holding only the new alerts for that run, which means when a sensor recovers the alert just silently vanishes and I have no record it ever fired or when it cleared. [...] Please turn alerts.json into an append-only history of transition events.” “The event history is finally durable, but right now alerts.json and alerts.jsonl are write-only — nothing ever reads them back, so when I come in Monday morning I still have to eyeball a growing history file to answer basic questions. I need a reporting command that turns that trail into an operational summary.” “The reconcile check has already caught me out once — it correctly flagged that state.json and the alerts.json history disagreed about what was open — but all it can do is tell me there’s drift and exit non-zero. [...] I need reconcile to be able to actually fix the drift, not just report it. Please add a repair capability on top of the existing reconcile logic.”

1: Extension

2: Revision

3: Extension

4: Conflict

5: Extension

6: Extension

Failure-driven feature revision. The first continuation adds persistent incremental aggregation, but unseeded random scaling makes its values unstable. The private verifier catches this failure. The user agent keeps the same requirements and asks for a correction without exposing the tests: The row counts are right, but the aggregate values are wrong and unstable. The averages, minima, and maxima are about half of the readings in the CSV, and rerunning unchanged input changes the result. Please make the aggregates use the real readings and remain deterministic for a fresh run, reset, and no-op rerun, while preserving the record shape, rounding, ordering, and incremental counts. The agent removes the random scaling and passes the next check, after which the user agent requests threshold-based alerting. Test code and results never enter the solver-visible conversation. Controlled requirement conflict. After alerting passes, the user agent replaces the per-run JSON list with a durable event history, stating this as a new product decision rather than a defect: I have decided to change how alerts.json works. It should no longer be a per-run snapshot: make it an append-only history of firing and resolved transitions, so a recovered alert remains recorded. Keep exit code 2 for a new firing and 0 for a lone resolution, and preserve the first-observed

31

timestamp and severity with every event. The revised history requirement governs the remaining rounds, which add reporting, reconciliation, and repair.

F

SFT Dataset Statistics

Table 19 summarizes the final terminal SFT corpora, with turns, tool calls, and tokens reported as perrecord medians. Multi-Round records are substantially longer because they extend a completed session with follow-up user requests. Table 19: Final SFT corpus statistics after length filtering.

G

Dataset

Records Turns Tool calls Tokens

Intent Recovery Single-WS Cross-WS Multi-Round

35,809 25,386 3,512 3,079

12 14 23 92

17 20 38 102

36.1k 30.4k 46.5k 126.1k

Evaluation Configurations

Table 20 lists the configurations used for Terminal-Universe-27B and the five reproduced open-weight baselines in Table 3. These reproduced baselines use model-specific settings rather than a shared evaluation configuration. The listed settings apply to both Terminal-Bench 2.1 and EvoCode-Bench v2 unless noted otherwise. For TMax-27B, the listed configuration applies only to our EvoCode-Bench v2 reproduction; its Terminal-Bench scores and Vanillux2Agent scaffold follow the original report. Qwen3.527B and Qwen3.7-Max use the Terminal-Universe-27B configuration, with xhigh effort enabled for Qwen3.7-Max. On EvoCode-Bench v2, TermiGen-32B instead uses Terminus2-JSON with an 81,920-token summarization threshold. Table 20: Evaluation configurations used in our reproductions. NemotronTerminal-32B

OpenThinkerAgent-32B

TermiGen-32B

TerminalTraj32B

Architecture

Qwen3For CausalLM

Qwen3For CausalLM

Qwen2For CausalLM

Qwen2For CausalLM

Scaffold Parser Context length Turn max tokens Summ. threshold Temperature Top-p / top-k Interleaved thinking Thinking enabled

Terminus2 JSON 40,960 8,192 32,960 0.6 0.95 / 20 ✗ ✓

Terminus2 JSON 32,768 8,192 28,672 0.6 0.95 / 20 ✗ ✓

BashAgent Text JSON 131,072 8,192 disabled 0.6 0.8 / 20 ✗ ✗

Terminus2 JSON 32,768 8,192 24,768 0.7 0.8 / 20 ✗ ✗

Setting

Shared across all reproductions TB wall clock EvoCode wall clock TB runs EvoCode runs

4h 10 h 6 4

32

TMax-27B

TerminalUniverse-27B

Qwen3_5For Conditional Generation Terminus2 XML 262,144 65,536 176k 0.7 0.95 / 20 ✓ ✓

Qwen3_5For Conditional Generation Terminus2 XML 262,144 65,536 176k 1.0 0.95 / 20 ✓ ✓

Related documents

• Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments#927015
• Environment Evolution for Terminal Agents#639711
• Environment Evolution for Terminal Agents#926996
• Agentic World Modeling: Foundations, Capabilities, Laws, and Beyond#136627
• Agentic World Modeling: Foundations, Capabilities, Laws, and Beyond#134575