What it is
Canoryn is a native macOS app I’ve been building since November 2025. It’s a place where I can work with AI agents on real workflows — not just chat transcripts that disappear.
Work shows up as .cryn graphs: triggers, browsers, model nodes, Mac actions, control flow, and Markdown outputs. I can open a graph, change a model or prompt, rewire a step, and decide when something is allowed to run outside the app.
Local-first matters here. Workflows, chat, and evidence stay on my machine.
Why I built it
When I’m using several agents at once, I keep losing the thread:
- What did it actually build?
- Which prompt / model / tool did it use?
- Can I change one piece without regenerating everything?
- Where do approvals and permissions live?
- How do I keep chat, CLI, files, and browser work in one place?
Canoryn is my answer: one visual workspace, with the files still owned by me.
What’s in the demo video
The video is short on purpose. I open Home, jump into Architect (the canvas), and show Multi-Model Research Studio — a workflow built during Build Week with Codex.
You’ll see browser sources and separate reasoning stages for OpenAI, Claude, Gemini, and Ollama, then synthesis / review into a Markdown brief on the same canvas.
Honest note: this cut is a product tour of an existing workflow. It does not show a live build or a full live run. I ran out of time to edit audio onto a live session; the narration (or description) covers Codex + GPT-5.6.
What changed in OpenAI Build Week
Canoryn already existed. During Build Week I used Codex with GPT-5.6 as my main engineering partner and pushed the authoring loop hard:
- Workflow DSL + compiler → validated visual graphs that start disabled
- Semantic canvas inspect / edit, plus Patch DSL for one-field changes without a full rebuild
- MCP + CLI so Codex (and Claude / Cursor / Antigravity) can author against the same engine
- Persistent native chat + CLI sessions
- Spatial research boards with real browser nodes and Markdown artifacts
- Clearer draft vs enable vs consent vs run behavior
- Better model/config controls, validation, tests, and guardrails
Enabling a workflow is what lets external CLI/MCP callers run it. Canvas Play and external run stay under lifecycle + consent rules.
How I used Codex and GPT-5.6
Primary collaborator for qualifying work: Codex + GPT-5.6.
It helped with the DSL/compiler, canvas inspect/patch, CLI/MCP authoring, chat reliability, lifecycle bugs, demo workflows, tests, and the evidence trail.
I kept product direction, security calls, acceptance, and final integration. Claude (and others) showed up as a second review pass — I’m not claiming Codex was the only model in the room.
Evidence file in the repo: docs/OpenAIBuildWeekCodexEvidence.md (baseline vs Build Week work, sessions, history).
Primary Codex session ID: 019f4ddf-f09a-7191-8992-8d5bcd438a67
Example workflows
Multi-Model Research Studio (in the video): browsers → OpenAI / Claude / Gemini / Ollama → synthesize → adversarial review → Markdown brief.
Morning Brief (CLI / DSL): Start → weather + calendar + reminders → OpenAI → Markdown. I also verified Patch DSL can change one field without rebuilding the graph.
Why this is useful
I don’t want automation that I can’t see or steer. Canoryn lets an agent help author a workflow while I still inspect it, tweak it, and choose when execution is allowed. The graph stays visible, editable, reusable, and local.
How to run it
Needs: macOS 14+, Xcode if building from source, at least one model provider for AI nodes.
From source: clone → open Aura.xcodeproj → scheme Canoryn → My Mac → ⌘R.
Providers: Settings → configure OpenAI and/or local (Ollama / LM Studio). Keys go in macOS credential storage.
CLI / MCP: Settings → CLI & MCP → install → new Terminal → canoryn --version. Keep the app running. Canvas, CLI, and MCP share the same engine.
Links
- Source: https://github.com/procodeai/canoryn
- Site: https://canoryn.app
- Docs: https://canoryn.app/docs
- Releases: https://github.com/procodeai/canoryn-releases
- Demo: https://youtu.be/eevcM_nd1SE
