Dorf
Durable AI workers on infrastructure you control.
Dorf makes your coding agent a durable worker—Codex today, more harnesses over time. Give it a job, walk away, and come back to the same work.
Each Worker gets a full development environment for its native tools and workflows. The Room keeps that work isolated from the rest of your infrastructure.
Run a coding Job
Install Dorf and run the one-time guided setup:
uv tool install dorf
dorf setup
See Getting started for current prerequisites and setup details.
Then create a Worker and give it one complete goal:
dorf worker spawn python-developer
dorf job assign build-retry-queue \
--to python-developer \
--goal "Build a small Python retry queue with tests, run them, and publish the results as evidence."
dorf job wait build-retry-queue
Close the terminal while the Job runs, then return from another shell:
dorf job inspect build-retry-queue
dorf job message build-retry-queue "Add a test for exponential backoff and publish the new results."
dorf job wait build-retry-queue
Workers do Jobs in Rooms
| Resource | Meaning |
|---|---|
| Worker | Durable identity around an agent harness |
| Job | Pinned goal with its own conversation and retained evidence |
| Room | Isolated environment supplied by a Room provider |
An Assignment records the exact Worker, Job, and Room binding for lifecycle and recovery. Most human-facing commands need only the Worker or Job name.
Workers wrap the harnesses developers already use; they are not a replacement agent framework. The control plane is harness- and sandbox-provider agnostic by design. Codex and local Incus VMs are the only supported adapters today; other harnesses and local or cloud VM providers can fit the same boundaries once validated.
Why Dorf
- Leave without losing the thread. Worker and Job identity survive the client that started them.
- Return to the situation, not a transcript. Inspect state, timeline, and evidence without asking the Worker to recap.
- Let the harness do its best work. Give it a complete development environment and contain that environment with a clear isolation boundary.
- Build workflows above the runtime. Dorf owns durable execution; applications own policy, acceptance, and presentation.
Alpha status
Dorf is alpha software. See Setup support for current adapters, host requirements, and limitations.
Coding-to-PR showcase
Coding-to-PR is the first application built on Dorf, not the runtime's identity. It takes a coding task from an isolated workspace through checks, review, follow-up, and a PR proposal.
dorf start "Fix the checkout timeout and add a regression test"
# Or leave an issue running unattended:
dorf afk 42
dorf job inspect JOB
dorf job inspect JOB --json # structured outcome pulse for agents
dorf verify JOB
dorf publish JOB
New coding Jobs use the Provider Connection selected by dorf setup. Pass
--provider-connection NAME only to intentionally override that host-local default.
The official dorf-codex image is the coding workstation: repository preparation and checks come
from the cloned repository's contract, while GitHub access remains a separately scoped host-side
integration. See the
North Star for how it fits
the broader runtime.
Build on Dorf
Build workflow-specific applications with the experimental Python SDK. It exposes the same Worker, Room, Job, and Assignment controls used by the CLI; coding-to-PR is the first example.
from dorf import Dorf
def run_coding_workflow(task: str) -> str | None:
with Dorf.open(provider_connection="personal-chatgpt") as dorf:
dorf.spawn_worker("developer")
dorf.assign_job(
"implementation",
worker_name="developer",
goal=(
f"{task}\n\n"
"Acceptance:\n"
"- Run the repository checks.\n"
"- Publish the results as evidence."
),
)
result = dorf.wait_for_job_input("implementation")
if result.outcome != "done":
raise RuntimeError(result.detail or result.outcome)
return result.response
The SDK is experimental and does not yet carry a third-party compatibility promise. See the Runtime Surface for the current responsibility boundary.
Learn more
- Documentation — choose a path by what you are trying to do
- Getting started — create your first Worker and Job
- North Star — approved product direction
- Setup support — host support, diagnostics, and troubleshooting
- Contributing — development workflow and DCO sign-off
- Security policy — private vulnerability reporting
Dorf is licensed under the Apache License 2.0.
Metadata
Release files for dorf 0.1.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| dorf-0.1.2.tar.gz | 143.6 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| dorf-0.1.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 307.9 kB
Release files / dorf-0.1.2.tar.gz
| Download URL | dorf-0.1.2.tar.gz |
|---|---|
| Size | 143.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
e084c70691820de1112524d6eeaf18aa6b5f837d9fa2e0d5c0ad8facbb22711d
|
|
BLAKE2b-256 checksum How to use checksums |
0c113563c6c0f585054e03b6b60191b63686c727e062676f496d7e61643d300f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 5, 2026.
Transparency logRelease files / dorf-0.1.2-py3-none-any.whl
| Download URL | dorf-0.1.2-py3-none-any.whl |
|---|---|
| Size | 164.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
78b452b8e9be33794c502bc6bf02d6b7250c105c2d2f9f4cdefe18d1748235dc
|
|
BLAKE2b-256 checksum How to use checksums |
2755188178e84ed720dc3c222d57a444108c8f4f2fd66841fedc55ab591ca324
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 5, 2026.
Transparency log