A Rust terminal engine and macOS terminal application built for agent-driven workflows.

Author: Andrew Yates andrewyates.name@gmail.com Version: 0.9.0 License: Apache-2.0 Copyright: 2026 Dropbox

dTerm delivers a Rust terminal core, a C FFI surface, Swift bindings, a command-line interface, and a macOS app. The engine tracks terminal protocol state, renders modern terminal media formats, and exposes structured screen state for tools that need to inspect terminal content without scraping pixels.

Current product focus: Track B, dTerm.app, is the active primary deliverable. Track A (Alacritty fork), Track C (dterm-linux), and DashTerm2 are deferred; DashTerm2 is historical only.

This README describes implemented source surfaces. It is not a release verdict, benchmark claim, or readiness claim. Reviewer-facing claims such as "release ready", "fastest", "best", "no flaws", or "ready" require fresh passing verifier evidence on the reviewed commit:

dterm verify
dterm verify launch
dterm verify performance --benchmark-report reports/benchmarks/benchmark.evidence.json

Accept launch evidence only when dterm verify launch exits 0 and the generated reports/hackernews-launch//claim-verdict.json records state=COMPLETE, verdict=PASS, exit_code=0, and a git_head matching the commit under review. A failed, interrupted, stale, dirty-tree, or partial run is blocking evidence, not a caveated pass. Benchmark or superiority language is valid only for the exact metrics, competitors, dates, and artifacts accepted by that proof. The command prints the exact run directory plus summary.md, claim-verdict.json, and blockers.jsonl; cite those paths rather than a nearby historical report.

Accept release-readiness evidence only when dterm verify exits 0. It prints a structured readiness report with aggregate metrics and a per-slot gate table before failing when any gate is open. The report also lists incremental progress, selected evidence sources, a gate detail table with observed metrics, goals, and gaps, and the required next step for every open gate. There is no report-only success flag for verification commands: open gates, missing evidence, stale evidence, dirty-tree provenance, or artifact write failures are blockers.

Benchmark failures are especially strict. If the launch report says benchmarks.external_required_metrics_missing or benchmarks.normalization_failed, the release claim is blocked until real raw samples cover every required competitor and metric pair that the safe local collectors cannot own, the benchmark normalizer emits a PASS artifact, and the one-command proof accepts that same artifact. The current collector contract is the benchmark collector audit embedded in the launch profile: startup, PTY and scroll throughput, memory RSS, first-frame, input-latency, resize-latency, GPU frame-time, and frame-jitter. Direct and dTerm input samples use local CGEventPostToPid against benchmark-owned app PIDs; Ghostty uses its captured terminal action path; other macOS open-app terminals use exact-PID-focused local event delivery with a System Events fallback; Terminal.app and third-party terminals use captured, window-scoped AppleScript sessions. Do not convert prerequisite reports, missing-sample next steps, app-RSS ownership fallbacks, fallback rows, or fail-closed benchmark JSON into "fastest" or "best" wording.

Build from source:

git clone https://github.com/andrewdyates/dterm
cd dterm
cargo build --release --bin dterm
cargo build --release -p dterm-cli

Build the macOS app:

swift build --package-path apps/dterm-mac

Run the command-line entry points from a checkout:

cargo run --bin dterm -- --help
cargo run -p dterm-cli -- --help

Verify and benchmark through the native dterm CLI:

dterm verify
dterm verify all
dterm verify function
dterm verify daily-driver
dterm verify suite e2e --surface dtermapp --AI Model-session require --prompt-editing emacs
dterm verify suite formal --formal-depth full
dterm bench --quick
dterm verify performance --benchmark-report reports/benchmarks/benchmark.evidence.json
dterm bench --compete-local --write-external-sample-files reports/benchmarks --json --save reports/benchmarks/bench-compete.raw.json
dterm bench --compete-local --skip-local-competitors --write-external-sample-files reports/benchmarks --json --save reports/benchmarks/bench-compete.raw.json
dterm verify plan launch
dterm bench --json --save reports/benchmarks/current.json
dterm formal tlc violations
dterm build check

Use CLI options for proof gates. Shell and Python test launchers are not supported proof interfaces for dTerm's first-class suites. Verification commands fail closed and live under dterm verify; do not rely on hidden aliases or report-only success modes. The daily-driver claim proves the actual dTerm.app product surface and hard-gates authenticated AI Model real-session evidence. Use dterm verify launch or dterm verify suite e2e --surface all when you need the broader compatibility lane that also exercises Alacritty.

Performance proof has one public surface: dterm verify performance. Keep dterm bench as the lower-level local benchmark runner; do not use or add a standalone dterm-bench binary or benchmark sample package. Release benchmark claims require dterm verify performance evidence showing dTerm rank 1 for every required performance and memory metric against every required terminal. --benchmark-report accepts strict benchmark.evidence.json or raw bench-compete-local JSON; raw input is normalized inside the verify run and still fails closed on stale commits, missing samples, or non-strict-best results. Use dterm bench --compete-local --write-external-sample-files reports/benchmarks to write the canonical raw bench-compete-local artifact and the exact pending per-terminal external sample files. By default, --compete-local attempts native local GUI competitor acquisition before recording blockers. That local acquisition captures the competitor metrics that can be measured safely from installed apps, such as startup, vtebench throughput for launch styles with an owned process, and process RSS where available; strict UI metrics that cannot yet be captured natively remain pending external sample rows and blockers. Add --skip-local-competitors only when the run should not launch local competitor terminals; it does not relax the proof gate or fabricate samples. The command records terminal inventory and exits non-zero until every required competitor has real same-commit samples for every required metric.

Run the macOS app during development:

swift run --package-path apps/dterm-mac dTerm

The macOS app is built on the Rust engine through Swift bindings. It includes Metal rendering, tabs and split panes, keyboard shortcuts, selection and clipboard integration, find/search, configurable themes, VoiceOver support, and session persistence.

The perception API exposes structured terminal state to Rust callers and the CLI. Callers can read screen text, semantic regions, links, interactive elements, and command blocks without reparsing raw PTY streams.

dTerm is organized as a layered multi-crate Rust workspace. Leaf crates provide parsing, encoding, storage, syntax, and terminal protocol helpers. Domain crates handle terminal state, rendering, media, security, search, shell integration, and input handling. The hub crate is dterm-core, with C headers in the FFI layer and Swift bindings under packages/dterm-swift/. The frontend layer includes dTerm.app in apps/dterm-mac/, dterm-cli, and dterm-linux.

dTerm exposes a C API for embedding in native applications.

#include "dterm.h"

struct DtermTerminal *term;
enum DtermTerminalError err = dterm_terminal_new_v2(24, 80, &term);
dterm_terminal_process_v2(term, data, len);
dterm_terminal_free(term);

Swift integration is provided by the package in packages/dterm-swift/, which wraps the exported C headers for the macOS app and Swift callers.

Common checks from a source checkout:

cargo fmt --all --check
cargo build --workspace
cargo test -p dterm-types --test domain_abstractions

The workspace also includes targeted Rust tests, Miri-oriented test modules, fuzz targets, and benchmark harnesses for terminal parsing, rendering, FFI, and protocol behavior.

Apache-2.0. See LICENSE for details.

Copyright 2026 Dropbox