I turned my Claude Code + Codex routine into a repeatable pipeline (open source, local-first)

AI coding agents got good. Claude Code and Codex can read a codebase, plan, implement and review. But in my daily work the agent was never the slow part. The slow part was the routine around it:

1. Read the ticket.
2. Ask one agent for a plan, and read it.
3. Tell it to implement.
4. Run the tests.
5. Paste the diff into a second agent for a review.
6. Decide which findings matter and send them back.
7. Run the tests again, then open a draft PR.

I was the glue between every step, I did it slightly differently each time, and when something went wrong I had no record of where. So I built the tool I wanted: Orchevia, a free, open-source (Apache-2.0) desktop app for Linux and macOS.

What it does

Orchevia turns that routine into a workflow graph. Each step is a node: AI agent, shell command, Git, GitHub, Jira ticket, MCP tool, condition, or human approval. The run above is the flow I use most:

• Ticket: load the Jira ticket (through your Jira MCP server).
• Plan: Claude writes a plan, and the run pauses for my approval.
• Implement: Claude implements the approved plan, then my real test command runs.
• Review: Claude and Codex review the diff in parallel, independently.
• Fix: a condition checks for P0/P1 findings; if there are any, a fix step runs, at most twice.
• Draft PR: gh opens a draft PR. Nothing merges; that stays a human decision.

Four design decisions

1. It's not an AI provider

There's no account, no API key field and no telemetry. Agent steps run the CLIs you already installed and signed in to, so they use your existing subscriptions and limits:

• Claude: claude -p --output-format stream-json …, prompt on stdin
• Codex: codex exec --json … -, prompt on stdin

Prompts go through stdin, so prompt text never becomes command-line flags and never shows up in process listings. Git and GitHub steps use your own git and gh. Workflows and run history live in local SQLite.

2. Predictable, not autonomous

I didn't want another agent deciding what to do next. A workflow is a fixed DAG:

• Conditions: constrained expressions, no scripting.
• Loops: bounded, with a maximum number of visits.
• Timeouts: every step has one, and a timeout stops the whole process group, so child processes like MCP servers stop too.
• No surprises: nothing runs until you press Run. Opening, importing or generating a workflow never executes anything.

Every write (commit, push, PR, comment) is an explicit node you can see. A passing test never merges anything unless you added that step.

3. Two reviewers beat one

Claude and Codex miss different things. Running both on the same diff catches more than either alone. Their findings are normalized to P0–P3, so a condition on node.claude-review.severity (P0 or P1?) decides whether to loop back to a fix step or move on, and the loop stays bounded.

4. You stay in the loop

• Approvals: Human Approval gates survive restarts.
• Cancel: runs can be cancelled at any time.
• Snapshots: every run keeps a read-only snapshot of the exact graph it ran.
• Recovery: a failed run can be recovered from its original inputs instead of starting over.

Generate a workflow from a goal

You don't have to draw graphs. Write the goal like a short spec, and your own Claude Code or Codex drafts it. Point it at a repository and the draft uses your real paths and test commands:

Read Jira ticket {{input.ticket}} and plan it with Claude, then pause for my approval. Implement it on branch {{input.branch}}, run pnpm test, and have Claude and Codex review the diff in parallel. Fix P0/P1 findings (at most twice), then open a draft PR.

The preview lists every step, the risk categories ("Modify local files", "Push / create or comment on PRs", and so on), anything you still need to set up, and every repair the compiler made. Nothing runs until you accept it and press Run. There are also nine built-in templates, from "implement a task" and "review a pull request" to "address review feedback" and "ticket to PR". A Dry run mode runs the routing against fixtures without executing anything.

See what happened, and what it used

Every run has a timeline: parallel steps on one time axis, each step's live output, the findings, which conversation a step resumed, and what each CLI reported.

A usage page breaks down agent attempts, tokens and tool calls by workflow, profile and model. Dollar figures a CLI reports are kept separate from what you actually pay on a subscription, and an optional guard can stop a run that crosses a reported-spend limit.

Automation that stays on your machine

Workflows can run on a schedule (interval, daily, weekly or cron), or from GitHub watchers:

• when a review is requested from you;
• when a PR you watch gets a new commit;
• when new review feedback arrives.

Anything that writes needs an explicit trust opt-in per schedule. There's no cloud worker: Orchevia runs these while it's open, and background mode keeps it running when the window closes.

Things I learned building it

• Headless agents can't ask for permission mid-run. A headless Claude that is refused a tool quietly tries another. Orchevia reads Claude's permission_denials and fails the step visibly, with the exact allow rule to add. You also decide once, app-wide, whether agents may work without asking or should follow each CLI's own settings.
• Explicit writes build trust. Once pushes and PRs became visible nodes, letting automation run became much easier.
• Local-first means honest limits. If Orchevia isn't running, schedules don't run. A slot missed while it was closed follows a "skip" or "run once" policy, instead of a catch-up storm.

Stack

• App: Tauri 2, with a React and TypeScript UI.
• Core: a Rust crate holding the workflow model, validation, the DAG engine (up to 4 steps at once), the scheduler and SQLite storage.
• Shell: the Tauri layer is a thin set of commands over that core. A browser mock backend keeps pnpm dev usable without the desktop app.

Try it

• Download: macOS (Apple Silicon and Intel), Linux AppImage and .deb from the latest release.
• Debian and Ubuntu: use the signed apt repository, so sudo apt upgrade keeps it current:

curl -fsSL https://iazaran.github.io/orchevia/apt/orchevia-archive-keyring.gpg | sudo tee /usr/share/keyrings/orchevia-archive-keyring.gpg > /dev/null
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/orchevia-archive-keyring.gpg] https://iazaran.github.io/orchevia/apt stable main" | sudo tee /etc/apt/sources.list.d/orchevia.list
sudo apt update && sudo apt install orchevia

• First run: the setup wizard finds git, gh, claude and codex on your login shell's PATH and creates recommended profiles. Then pick Samples… → Plan → Implement → Review and press Run.

Honest caveats: the macOS builds aren't notarized yet, so macOS asks you to confirm the first launch, and Windows isn't supported yet.

iazaran / orchevia

Run Claude Code and Codex CLIs as reviewable, repeatable workflows on your own machine: visual editor, approvals, Git/GitHub/Jira steps, schedules and PR watchers. Local-first desktop app with no account, no API keys and no telemetry.

Orchevia

Run your Claude Code and Codex CLIs as reviewable, repeatable pipelines — on your own machine.

Download · Website · Getting started · Docs · Changelog · Report an issue

Orchevia is a local-first desktop app that turns the work you already do with AI coding CLIs into a graph you can inspect, repeat and share. Describe a task — "plan this ticket with Claude, let me approve it, implement, run the tests, have Claude and Codex review, fix P0/P1 findings, open a draft PR" — check the graph, press Run and every step executes through tools already installed on your machine: Claude Code, Codex, git, gh, your test commands.

Orchevia is not an AI provider. There is no Orchevia account, no model API key field, no telemetry and no hosted runner. AI work goes through the CLIs you installed and signed in to yourself…

View on GitHub

If you use Claude Code or Codex every day, I'd like to hear how you'd use this and what's missing: comments here, issues or Discussions. The website also has an interactive replay of a real run.

Comments

[tamina]

The design choice that stands out to me is treating every write — commit, push, PR — as an explicit visible node instead of a side effect of the agent. That's the part most agent wrappers skip, and it's exactly why people hesitate to trust scheduled runs. Surfacing permission_denials as a failed step with the exact allow rule is a nice touch too; a headless agent quietly routing around a refusal is the worst failure mode. Curious how the bounded fix loop behaves when the two reviewers disagree on severity for the same finding — does it take the max?