LiberCoder: CLI Repair Code Agents

• LiberCoder is a pair of open-weight, instruction-tuned code agents specializing in environment-centric CLI repair tasks, enabling robust shell interaction and debugging.
• It leverages the CLI-Gym pipeline to generate reproducible failure tasks through Docker-based environment perturbations and automated repair strategies.
• Evaluation on Terminal-Bench shows significant gains with variant scores up to 46.1, underscoring its effectiveness over other open-weight models.

LiberCoder is a pair of open-weight, instruction-tuned code agents specialized for environment-centric command-line interface interaction, introduced alongside the CLI-Gym pipeline for scalable derivation of environment-intensive repair tasks. The two variants, LiberCoder-32B and LiberCoder-235B-A22B, are obtained by supervised fine-tuning Qwen3 models on executable, verifiable trajectories that emphasize shell interaction, environment diagnosis, dependency repair, and system-level debugging rather than code-only editing. In the reported evaluation, LiberCoder-235B-A22B reaches 46.1 on Terminal-Bench 1.0 and 31.0 on Terminal-Bench 2.0, with substantial absolute improvements over its base model and strong open-weight baselines (Lin et al., 11 Feb 2026).

1. Model family and agent interface

LiberCoder comprises two fine-tuned model variants. LiberCoder-32B fine-tunes Qwen3-32B, and LiberCoder-235B-A22B fine-tunes Qwen3-235B-A22B-Instruct. The architecture inherits Qwen3’s long-context transformer, and training extends the usable window to 100k tokens via YaRN with an expansion factor of 2.5. Inference uses up to 128k tokens. The models are not presented as pure text generators; they operate through the OpenHands Agent–Computer Interface, where actions are structured tool calls rather than free-form text (Lin et al., 11 Feb 2026).

The core tools are execute_bash, think, finish, execute_ipython_cell, str_replace_editor, and task_tracker. Within this interface, LiberCoder supports full shell and CLI interaction in isolated Docker containers, file editing and inspection, environment introspection, conda environment management, and pytest execution. The execute_bash tool provides a persistent shell session and supports command chaining with && and ;, while think supports internal reasoning and logging without changing environment state, and finish provides explicit task termination with a summary. The design couples reasoning and action under execution feedback through OpenHands, and the paper explicitly notes that a dedicated think tool supports reasoning akin to ReAct-style planning, while not claiming the method is ReAct (Lin et al., 11 Feb 2026).

A further operational feature is deterministic environment reconstruction. The agent writes commands it actually executed, and those commands are summarized into a Dockerfile appended to the gold image’s Dockerfile. The sandbox setup relies on docker-compose.yaml to mount trajectories and logs, and run-tests.sh orchestrates unit-test execution in a conda environment named testbed for verification. This makes the agent interface central not only to inference but also to data generation and reproducibility.

Variant	Base model
LiberCoder-32B	Qwen3-32B
LiberCoder-235B-A22B	Qwen3-235B-A22B-Instruct

2. Formalization and CLI-Gym generation pipeline

The paper formalizes an environment state as

$$\mathcal{S} = (\mathcal{B}, \mathcal{D}, \mathcal{C}),$$

where $\mathcal{B}$ is the base environment, $\mathcal{D}$ is the Dockerfile describing environment construction, and $\mathcal{C}$ is the codebase. Forward agentic repair maps a poor state to a gold state through changes to Dockerfile and codebase, while inverse agentic data generation starts from a healthy state and perturbs it into a defective one. State construction is described through the operator $\oplus$, with

$$\mathcal{S}_{\text{poor}} = \mathcal{S}_{\text{gold}} \oplus (\Delta \mathcal{D}, \Delta \mathcal{C}).$$

In this formulation, $\mathcal{S}_{\text{poor}}$ fails at least one unit test and $\mathcal{S}_{\text{gold}}$ passes all unit tests (Lin et al., 11 Feb 2026).

CLI-Gym implements this inversion through “Agentic Dockerfile coding.” The agent starts from a healthy Docker image that passes all unit tests and deliberately induces failures while exploring environment histories. The perturbations may affect filesystem operations, virtual environment or conda state, dependency resolution through pip, conda, or system libraries, and system-level configuration such as locales, dynamic linking, and environment variables. Rather than synthesizing a fresh environment specification, the agent summarizes a Dockerfile of the commands it actually executed; appending this summary to the original image’s Dockerfile deterministically reproduces the failure state.

Failure generation is coupled to automated testing. After the agent acts, the harness runs run-tests.sh, which invokes pytest inside /opt/miniconda3/envs/testbed and logs output to /test.log through a tester.py wrapper that prints and line-buffers to stdout and file. If some unit tests fail, they are marked as fail-to-pass (F2P), and passing tests are marked as pass-to-pass (P2P). If the test command fails to execute, all selected unit tests are recorded as F2P. If all unit tests pass, the task instance is discarded. Problem statements are then generated from failing unit tests and the original sabotage prompt, optionally with hints; the reported ablation states that hints boost trajectory yield (Lin et al., 11 Feb 2026).

Each CLI-Gym task contains three elements: an executable environment consisting of a base image plus the summarized Dockerfile, a natural-language issue description, and unit tests specifying desired behavior through F2P and P2P sets. The degradation prompts specify Task Name, Category, Selected UTs, Task Description, Expected Result, and Recovery Strategy. The Degradation Instruction Template directs the agent to modify the environment and then summarize a Dockerfile capturing actually executed operations, with no comments, multi-line Dockerfile syntax, and no forensic breadcrumbs.

3. Dataset scope and task characteristics

CLI-Gym contains 1,655 environment-intensive tasks generated from 29 popular Python repositories sampled from SWE-Smith, making it the largest collection of its kind in the paper’s comparison. The dataset is reported as nearly 20× larger than Terminal-Bench v1.0, which has 80 tasks, and Terminal-Bench v2.0, which has 89 tasks. Its storage footprint is 119 GB for 1,655 tasks and 29 images, compared with 192 GB for 80 tasks and 14 images in Terminal-Bench v1.0, and 235 GB for 89 tasks and 11 images in Terminal-Bench v2.0 (Lin et al., 11 Feb 2026).

The paper reports average per-instance statistics for Terminal-Bench and CLI-Gym. Issue text length is 140.7 versus 159.1 words. Dockerfile length is 5.8 versus 6.8 lines. The number of F2P tests is 7.9 versus 20.4, and the number of P2P tests is 0.0 versus 29.6. Collection cost is described in organizational rather than monetary terms: Terminal-Bench involved 93 human contributors, whereas CLI-Gym is fully automated and required approximately 2.3B tokens.

The task distribution spans dependency resolution, configuration debugging, system administration, security, debugging, and libraries and frameworks such as pandas, scrapy, gunicorn, pyopenssl, .env loaders, and locale and I/O settings. Repository examples include pandas with 109,403 unit tests and 242 task instances, gunicorn with 248 unit tests and 160 tasks, ptyprocess with 12 unit tests and 109 tasks, scrapy with 2,882 unit tests and 119 tasks, and textdistance with 427 unit tests and 82 tasks (Lin et al., 11 Feb 2026).

A representative scaling comparison appears below.

Dataset	Instances	Storage
SWE-gym	2,438	6 TBs
SWE-smith	50,137	295 GBs
[email protected]	80	192 GBs
[email protected]	89	235 GBs
CLI-Gym	1,655	119 GBs

The dataset is available at https://huggingface.co/datasets/LiberCoders/CLI-Gym, and code is available at https://github.com/LiberCoders/CLI-Gym. Licensing details are not explicitly stated in the paper.

4. Fine-tuning recipe and supervision signals

LiberCoder is trained by supervised imitation learning on executable, verifiable trajectories. The paper does not report reinforcement learning or any explicit feedback-driven optimization algorithm, and it does not provide a training loss equation. Training proceeds in two stages. The first stage uses 48K open-source SWE-style trajectories to initialize general agentic coding capabilities such as repository navigation, tool invocation, and code repair; this dataset is stated to be disjoint from Terminal-Bench to avoid contamination. The second stage fine-tunes on environment-centric CLI-Gym trajectories, starting from 417 successful trajectories collected using strong LMs plus OpenHands, and filtering them down to 291 high-quality trajectories by removing trivial trajectories with fewer than 20 steps and cheating trajectories that exploit cache or unintended artifacts (Lin et al., 11 Feb 2026).

For Qwen3-32B, the reported hyperparameters are an initial learning rate of $2 \times 10^{-5}$ with cosine decay, linear warmup over the first 5% of steps from $1 \times 10^{-6}$ to $\mathcal{B}$0, batch size 16, epochs 10, 15, and 20 with the best validation checkpoint selected, maximum sequence length 100k tokens, and the qwen3-coder agent template. For Qwen3-235B-A22B-Instruct, the initial learning rate is $\mathcal{B}$1 with cosine decay, warmup is linear for the first 5% of steps from $\mathcal{B}$2 to $\mathcal{B}$3, epochs are again 10, 15, and 20 with best-checkpoint selection, and the maximum sequence length is 100k tokens with the same qwen3-coder template. Tokenization, optimizer choice, gradient clipping, weight decay, and exact loss are not specified.

At inference time for evaluation, the configuration uses greedy decoding with temperature $\mathcal{B}$4, maximum context length 128k tokens, and episode termination either through the finish tool or the global benchmark time limit. Episodes run in containers with one agent per task, and pass@k is measured through verification scripts. The supervision therefore includes both natural-language guidance and structured tool-augmented action schemas.

A common misconception is that LiberCoder is primarily a code-editing model adapted to CLI tasks after the fact. The paper instead presents the environment-centric trajectories as the critical specialization signal; code repair remains part of the action space, but the dominant training signal includes environment manipulation, test-driven diagnosis, and shell-based remediation.

5. Benchmark performance and ablation evidence

The primary evaluation uses Terminal-Bench 1.0 with 80 tasks and Terminal-Bench 2.0 with 89 tasks, where success is defined by passing benchmark verification scripts and both pass@1 and pass@3 are reported. With the OpenHands agent, the base Qwen3-32B scores 10.3 on Terminal-Bench 1.0 and 5.7 on Terminal-Bench 2.0, while the base Qwen3-235B-A22B-Instruct scores 25.0 and 18.1. After fine-tuning, LiberCoder-32B reaches 38.9 and 19.5, and LiberCoder-235B-A22B reaches 46.1 and 31.0. The corresponding absolute improvements are +28.6 and +13.8 for the 32B model, and +21.1 and +12.9 for the 235B model (Lin et al., 11 Feb 2026).

Model	TB1.0	TB2.0
Qwen3-32B	10.3	5.7
LiberCoder-32B	38.9	19.5
Qwen3-235B-A22B-Instruct	25.0	18.1
LiberCoder-235B-A22B	46.1	31.0

Against strong open-weight baselines using the best performance with any agent, LiberCoder-235B-A22B at 46.1 on Terminal-Bench 1.0 exceeds Qwen3-Coder-480B-A35B-Instruct at 39.0, GLM-4.6 at 40.5, and Kimi-K2-Instruct at 30.0. On Terminal-Bench 2.0, its 31.0 exceeds Qwen3-Coder-480B-A35B at 27.2, GLM-4.6 at 24.5, Kimi-K2 at 27.8, and GPT-OSS-120B at 18.7, while Minimax-M2.1 is higher at 36.6. For context, closed-weight systems reported as state of the art reach up to 64.7 for Gemini 3 Pro, 62.9 for GPT-5.2, and 57.8 for Claude Opus 4.5 on Terminal-Bench 2.0.

The ablations attribute the gains primarily to environment-centric supervision. On Terminal-Bench 1.0, pass@1 for Qwen3-32B changes from 10.3 at baseline to 22.1 with SWE pretraining only, 32.4 with CLI-Gym only, and 38.9 with SWE plus CLI-Gym. For Qwen3-235B, the sequence is 25.0, 28.6, 39.5, and 46.1. The paper’s conclusion is explicit: environment-centric supervision provides a stronger inductive bias than SWE-only, and combining both is best. Additional ablations report that, with fixed 100 trajectories, increasing the number of source repositories monotonically improves Terminal-Bench 1.0 performance; that performance improves as filtered trajectories are added until roughly 200 trajectories and then plateaus; and that adding hints in repair issues raises valid trajectory yield from 104 to 291, although controlling for data scale at 104 shows no significant downstream performance change from hints alone (Lin et al., 11 Feb 2026).

Behavior analysis links the improvements to reduced pathological interaction patterns. As filtered-success trajectories increase, “stuck in loop” failures drop from 42.7% to 3.0%. The paper also states that editing and localization errors drop substantially after training, although models may explore more and risk exceeding the 128k context window.

6. Failure modes, robustness, and reproducibility

The paper includes concrete examples of environment corruption used during data generation. One example corrupts system libraries in a pandas environment by modifying ELF headers for libsqlite3.so and libz.so, producing ImportError and broader CLI failures that require system diagnosis. Another poisons locale handling by writing /etc/profile.d/02-set-interval-locale.sh to export LC_ALL, LANG, LC_NUMERIC, and LC_MONETARY to a corrupted locale variant, disabling /usr/lib/locale/locale-archive, and injecting sitecustomize.py to set locale at interpreter startup; the resulting failures arise from misparsed numerics in pandas IntervalIndex tests (Lin et al., 11 Feb 2026).

These cases illustrate the intended task distribution: LiberCoder is trained to handle dependency chains, environment variables, filesystem state, dynamic linking, locale configuration, and unit-test feedback. The reported pretraining and fine-tuning sequence is associated with better dependency diagnosis, better configuration repair, fewer editing and localization mistakes, and improved escape from repetitive loops. A plausible implication is that the model’s advantage does not arise from repository navigation alone, but from exposure to executable system repair behaviors that are absent from code-only corpora.

The reproducibility story is strong at the task level. Summarized Dockerfiles reproduce failure states deterministically, each task runs in an isolated Docker container, tester.py executes pytest in the testbed conda environment, and run-tests.sh uses strict shell options set -uo pipefail -x together with --disable-warnings, --color=no, --tb=no, and --verbose. All stdout and stderr are streamed both to the console and /test.log, with carriage-return normalization. Environment inversion is reported to take approximately 15 minutes per synthesized task, and episodes end on finish or timeout.

Several limitations are explicit. The work focuses on Python repositories and CLI tasks; GUI tasks, services requiring credentials, gaming, and some scientific computing categories remain challenging. Upstream package updates may introduce environment drift despite Dockerfile-based degradation capture. Long-horizon tasks may exceed the 128k context window. OpenHands is general-purpose and may underperform benchmark-specific agents such as Terminus 2, and the paper shows notable agent variance on Terminal-Bench 2.0. The paper does not report optimizer details, loss equations, tokenization specifics, GPU or TPU types, training hours, memory budgets, or direct download links for the fine-tuned LiberCoder weights. Exact installation commands and licensing terms are likewise not included; the paper directs readers to the GitHub and Hugging Face pages for operational details (Lin et al., 11 Feb 2026).