OpenASE is an all-in-one platform that turns tickets into working code — AI agents automatically pick up tickets, execute workflows on your machines, and deliver results with full traceability.

The embedded web UI covers ticket orchestration, AI-assisted planning, skill authoring, and live project tracking.

Live execution
Monitor real project work as tickets move across backlog, todo, in-progress, and review.

Ticket board Manage backlog and execution flow with a kanban-style ticket view.	Project AI Break work into tickets and inspect workspace context directly beside the board.
Skill editor Edit built-in or custom skills that drive repeatable automation workflows.

AI coding agents are powerful — but only when humans stay in control. The real question is how that control works. OpenASE is built around two complementary modes of human–agent interaction: synchronous and asynchronous.

When the requirements are clear, the acceptance criteria are well-defined, and a Harness (a hard-boundary document that constrains agent behavior) is in place, the Ticket Agent executes the entire task autonomously. It follows the Workflow's instructions, updates ticket statuses, and completes the work described in each ticket — humans don't need to babysit.

The Workflow defines the status flow and tells the agent how to transition tickets through each stage. It is a soft control surface: you write natural-language instructions in the Workflow to guide how the agent should behave at each status. Here are two common patterns:

• Fullstack Coder — A single agent handles the entire lifecycle. Set up a simple status flow like Todo → In Progress → In Review → Merging → Done. The agent picks up a ticket, writes the code, opens a PR, and moves it forward. Human review at the In Review stage is optional — you can keep it for quality gates or let another agent handle the review.

• Mixed Relay — Multiple specialized agents collaborate in a relay. Set up a richer flow like Design → Backend → Frontend → Testing → In Review → Merging → Done, and assign different agent roles (product manager, backend engineer, frontend engineer, tester) to each stage. Agents hand off work to the next role as the ticket progresses. Human review checkpoints are optional at any stage — you can insert them where you want oversight, or remove them entirely for full autonomy.

Both async and sync AI support multiple agent CLIs. Claude Code and Codex are recommended for production use; Gemini CLI is supported but less stable.

When your requirements are still vague, the problem space needs exploration, or you're not ready to commit to a formal ticket — start a conversation with Project AI.

Project AI is a synchronous, interactive assistant that lives in the sidebar of the control plane. Use it to analyze requirements, explore technical approaches, draft PRDs and documentation, scaffold repositories, and prepare everything before kicking off async execution. Each conversation tab runs in an independent workspace — tabs are isolated, can run in parallel, and are easy to manage and review side by side.

What Project AI can do:

• Read ticket details, dependencies, activity history, and run status
• Read Workflow/Harness configuration, Skill code, and machine health
• Inspect git workspace diffs (branch, file changes, repo status)
• Create and update tickets, publish project updates
• Modify Workflows/Harnesses and Skills directly
• Trigger agent execution on tickets
• Operate git (commit, branch, push)
• Control agent runtimes (pause, resume, interrupt)

Multi-agent, isolated workspaces — in one panel: Each Project AI tab spawns its own isolated workspace. You can run multiple agents side by side in the same panel — each working on a different task, in a different branch, with zero interference. No more juggling terminals or switching between IDEs. One unified view to launch, monitor, and interact with all your agents simultaneously.

Context-aware focus: As you navigate the control plane, Project AI automatically switches between 4 focus modes — Workflow, Skill, Ticket, and Machine — injecting the relevant context into the conversation so it always understands what you're looking at.

Best practice: Start with a fuzzy idea, discuss it with Project AI to converge on the best approach, let it draft documents and initialize the repo. Then set up an automated Fullstack or Mixed Relay Workflow, configure ticket dependencies to control parallelism and blocking, and let the system run. With well-structured Harnesses and dependency graphs, the platform can sustain long periods of high-throughput autonomous work with zero human intervention.

Skills are reusable instruction documents that give agents extra capabilities beyond raw coding. Every Workflow automatically binds a built-in Ticket Skill that teaches the Ticket Agent how to update ticket statuses on the platform — this is how agents drive the status flow without hardcoded logic.

Beyond the built-in skills, you can:

• Bind more built-in skills to any Workflow for common operations (e.g., git conventions, PR creation, code review checklists).
• Create custom skills from the Skill Editor to encode project-specific knowledge and procedures.
• Import skills from your repository — ask Project AI to pull skill files from your repo and register them in OpenASE.

When a Workflow runs, its bound skills are injected into the CLI agent's skill directory at runtime (e.g., .codex/skills/, .claude/skills/, .gemini/skills/), so the agent picks them up natively. Project AI has access to all skills regardless of Workflow binding, making it the ideal place to author, edit, and debug skills before deploying them.

Best practice: Use Project AI to create, modify, or debug your skills interactively. Once a skill works as expected, save it to OpenASE and bind it to the relevant Workflows — every Ticket Agent that runs under those Workflows will inherit the skill automatically.

In practice, these two modes are constantly interleaved:

• Requirements change → existing Harnesses go stale and need synchronous refinement.
• Projects iterate → new Harnesses must be authored to prevent agents from drifting off course.
• Tech debt accumulates → scheduled jobs trigger agents to clean it up automatically on a cron.

This interplay of sync and async work deserves a unified home — not scattered across terminals, IDEs, and chat windows. OpenASE brings it all together: multi-agent CLI support (Claude Code, Codex, Gemini CLI), multi-machine scheduling, and a single control plane so you never have to context-switch between tools.

OpenASE supports multi-Organization management out of the box. Each Org contains its own set of Projects, and each Project has independent tickets, workflows, skills, machines, and agent configurations. Cross-Org team collaboration (shared projects, role-based permissions across Orgs) is currently WIP.

To maximize unattended Workflow execution efficiency, OpenASE launches CLI agents with permissive flags by default (e.g., --dangerously-skip-permissions for Claude Code, --yolo for Codex). This means agents can read, write, and execute arbitrary commands on the host machine without per-action confirmation. You can change this to standard (interactive) mode per-provider in the Provider settings page.

Be aware of the risks:

• Only run OpenASE on machines where you trust the agent's scope of access.
• Restrict OS-level permissions (user accounts, filesystem boundaries) as appropriate.
• This project is NOT designed for public-facing deployment. It is intended for local development, private networks, and trusted environments.
• Browser access is always authorization-gated. Fresh local installs start with local bootstrap links instead of anonymous admin access, and shared or networked deployments should move to HTTPS + OIDC as soon as practical. See the OIDC & RBAC Guide for the rollout model.

OpenASE aims to be a full-lifecycle software engineering platform: end-to-end iteration from ticket to deployed code, team collaboration across roles, and multi-repository orchestration — all driven by the ticket-first, agent-native model described above.

📋 Ticket-Driven Orchestration Kanban Board & List Views Parent/Child & Dependency Tracking Custom Statuses & Priorities Repository Scope Binding	🤖 Multi-Agent Support Claude Code / Codex / Gemini CLI Real-time Streaming Output (SSE) Agent Lifecycle Management Concurrent Execution Control	⚡ Workflow Engine Markdown Harness Documents Skill Binding & Lifecycle Hooks Scheduled Cron Jobs Built-in Role Templates
🖥️ Machine Management Local / Direct-Connect / Reverse-Connect Machines Websocket Execution + SSH Helper Compatibility Health Monitoring & Probes CPU / Memory / Disk Metrics Connectivity Diagnostics	🔐 Auth & Security OIDC Browser Login (Auth0, Entra ID) Agent Platform Token Auth Org & Project RBAC GitHub Credential Management	📡 Observability Live Activity Event Stream Agent Run Step Tracking GitHub Webhook Ingestion Project Update Threads

OpenASE is a single Go binary that ships an API server, workflow orchestrator, and embedded web UI together. It follows a ticket-driven model: every piece of work is a ticket, every ticket has a workflow, and AI agents automatically pick up and execute tickets based on status triggers.

You create a ticket  →  Orchestrator detects pickup status
    →  Agent claims the ticket  →  Executes workflow on a Machine
    →  Activity stream records every step  →  Ticket completes

No Node.js at runtime — the SvelteKit frontend is compiled and embedded into the Go binary via go:embed.

This section walks through everything you need on a fresh machine — from installing system dependencies to opening the web UI.

For fresh Linux or macOS machines, the fastest supported path is the release installer:

curl -fsSL https://raw.githubusercontent.com/pacificstudio/openase/main/scripts/install.sh | sh

The installer:

• detects the current OS, architecture, package managers, Docker usability, and writable install targets
• downloads the matching GitHub release archive plus checksums.txt
• verifies the release checksum before installing openase
• offers PostgreSQL bootstrap through a supported system package manager or Docker when available
• writes a runnable ~/.openase/config.yaml and ~/.openase/.env when automatic setup completes successfully

To pin a release version instead of installing the latest release:

curl -fsSL https://raw.githubusercontent.com/pacificstudio/openase/main/scripts/install.sh | sh -s -- --version v0.4.0

If you prefer to build from source, continue with the manual steps below.

# Download (adjust version and OS/arch as needed)
wget https://go.dev/dl/go1.26.1.linux-amd64.tar.gz

# Extract to /usr/local (requires sudo)
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.26.1.linux-amd64.tar.gz

# Add to PATH — append to ~/.bashrc or ~/.zshrc
export PATH=$PATH:/usr/local/go/bin

# Verify
go version   # go1.26.1 linux/amd64

export PATH=$PWD/.tooling/go/bin:$HOME/.local/go1.26.1/bin:$PATH

# Option A: via nvm (recommended)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.bashrc
nvm install 22
nvm use 22

# Option B: via package manager (Ubuntu/Debian)
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs

# Enable corepack for pnpm
corepack enable

# Verify
node --version   # v22.x.x
pnpm --version   # 10.x.x (via corepack)

# Install Docker if not present
sudo apt-get update && sudo apt-get install -y docker.io
sudo usermod -aG docker $USER
newgrp docker   # or re-login

# OpenASE setup will create the container for you automatically

# macOS via Homebrew
brew install postgresql@16
brew services start postgresql@16

# Verify a DSN that setup can reuse
psql postgres://localhost:5432/postgres?sslmode=disable -c "SELECT 1;"

# Ubuntu/Debian
sudo apt-get install -y postgresql postgresql-client

# Create database and user
sudo -u postgres psql -c "CREATE USER openase WITH PASSWORD 'openase';"
sudo -u postgres psql -c "CREATE DATABASE openase OWNER openase;"

# Verify
psql postgres://openase:openase@localhost:5432/openase?sslmode=disable -c "SELECT 1;"

# Ubuntu/Debian
sudo apt-get install -y git make curl wget

# Verify
git --version
make --version

git clone https://github.com/PacificStudio/openase.git
cd openase

# Build frontend + Go binary in one command
make build-web

This runs the following under the hood:

corepack pnpm --dir web install --frozen-lockfile
corepack pnpm --dir web run build
go build -o ./bin/openase ./cmd/openase

make build-web rebuilds the embedded frontend and then compiles the Go binary. It does not refresh the committed OpenAPI artifacts. If you changed backend API shapes or want to refresh api/openapi.json and web/src/lib/api/generated/openapi.d.ts, run make openapi-generate separately first.

Verify the build:

./bin/openase version

./bin/openase setup

The interactive terminal setup will walk you through:

1. Database — start a Docker PostgreSQL automatically, or enter an existing PostgreSQL connection (host, port, database, user, password, sslmode)
2. CLI detection — checks for git, claude, codex, gemini on PATH
3. Runtime mode — config-only, or install the managed user service (systemd --user on Linux, launchd on macOS)
4. Seed data — creates org, project, ticket statuses, and detected providers
5. Local browser bootstrap — after startup, generate a one-time local bootstrap link with openase auth bootstrap create-link --return-to / --format text

Setup creates the following under ~/.openase/:

~/.openase/
├── config.yaml       # Runtime configuration
├── .env              # Platform auth token
├── logs/             # Service logs
└── workspaces/       # Agent workspaces

Docker PostgreSQL note: When choosing Docker, setup uses predictable defaults — container openase-local-postgres, port 127.0.0.1:15432, database openase. It generates the password automatically. If your account does not have Docker access, setup does not offer another local-database fallback; prepare PostgreSQL first and then choose the manual connection path.

# All-in-one: API server + orchestrator in a single process
./bin/openase all-in-one --config ~/.openase/config.yaml

The control plane is now available at:

http://127.0.0.1:19836

Tip: Run ./bin/openase doctor --config ~/.openase/config.yaml to diagnose any issues.

# Health checks
curl -fsS http://127.0.0.1:19836/healthz
curl -fsS http://127.0.0.1:19836/api/v1/healthz

# Or use the built-in doctor
./bin/openase doctor --config ~/.openase/config.yaml

Open http://127.0.0.1:19836 in your browser — you should see the OpenASE control plane.

Now that the platform is running, follow the User Guide — Quick Start (EN | 中文) to:

1. Configure ticket statuses and connect a repository
2. Register a machine and an AI agent
3. Create your first workflow and ticket
4. Watch the agent execute automatically

Setup can install the managed user service automatically. You can also manage it manually:

./bin/openase up      --config ~/.openase/config.yaml   # Install & start
./bin/openase logs    --lines 100                        # Tail logs
./bin/openase restart                                    # Restart
./bin/openase down                                       # Stop

The managed service only runs OpenASE itself (openase all-in-one --config ...). It does not manage PostgreSQL for you. If you pointed OpenASE at an existing PostgreSQL instance, keep that database running separately. If setup created a Docker PostgreSQL container, that container is still a separate service boundary from OpenASE.

On macOS, setup prefers the gui/<uid>/com.openase target and falls back to user/<uid>/com.openase when the login session is attached to that domain instead. Use whichever target launchctl print resolves on your machine for kickstart and bootout.

For long-running Linux server use, systemd --user may also need lingering enabled so the user service survives logout and can start as expected after reboot:

loginctl enable-linger "$USER"

Run that once per user account on machines where you expect OpenASE to keep running without an active login session.

Run API server and orchestrator as separate processes:

./bin/openase serve       --config ~/.openase/config.yaml
./bin/openase orchestrate --config ~/.openase/config.yaml

If you prefer env vars over config files:

export OPENASE_DATABASE_DSN=postgres://openase:openase@localhost:5432/openase?sslmode=disable
export OPENASE_SECURITY_CIPHER_SEED=shared-cluster-seed
export OPENASE_SERVER_PORT=19836
export OPENASE_ORCHESTRATOR_TICK_INTERVAL=2s

./bin/openase all-in-one

Or source from ~/.openase/.env:

set -a && source ~/.openase/.env && set +a
./bin/openase all-in-one

OPENASE_SECURITY_CIPHER_SEED maps to security.cipher_seed in config files. If it is unset, OpenASE keeps the legacy behavior and derives the GitHub credential cipher seed from database.dsn.

1. --config <path> flag
2. ./config.yaml (or .yml, .json, .toml)
3. ~/.openase/config.yaml
4. OPENASE_* environment variables + built-in defaults

• Fresh local installs use one-time local bootstrap links for browser authorization; they no longer expose anonymous admin access.
• OIDC remains the long-term browser auth path for shared, team, and networked deployments.
• If an active OIDC rollout breaks login, use openase auth break-glass disable-oidc, then re-enter through openase auth bootstrap create-link --return-to /admin/auth --format text.

OIDC supports standard providers: Auth0, Azure Entra ID, and any OpenID Connect compliant IdP. See the IAM Dual-Mode Contract (EN | 中文) for the product model, and the OIDC & RBAC Guide (EN | 中文) for setup.

openase/
├── cmd/openase/              # CLI entrypoint
├── internal/
│   ├── app/                  # App wiring (serve / orchestrate / all-in-one)
│   ├── httpapi/              # HTTP API, SSE, webhooks, embedded UI
│   ├── orchestrator/         # Scheduling, health checks, retries
│   ├── workflow/             # Workflow service, harness, hooks, skills
│   ├── agentplatform/        # Agent token auth
│   ├── setup/                # First-run setup
│   ├── builtin/              # Built-in role & skill templates
│   └── webui/static/         # Embedded frontend output
├── web/                      # SvelteKit control plane source
├── docs/
│   └── guide/                # User guide (per-module docs)
├── config.example.yaml
├── Makefile
└── go.mod

flowchart LR
    U[User / Scheduled Job] --> T[Ticket]
    T --> O[Orchestrator]
    O -->|status trigger| A[Agent]
    A --> W[Workflow + Harness]
    W --> S[Skills]
    A -->|executes on| M[Machine]
    M --> R[Results]
    R --> E[Activity Stream]
    E --> UI[Web Control Plane]

The embedded web UI provides a complete project management experience:

OpenASE follows a GitHub-style dual-layer CLI contract:

openase ticket list       --status-name Todo --json tickets
openase ticket create     --title "Fix login bug" --description "..."
openase ticket update     --status_name "In Review"
openase ticket comment    create --body "Blocking dependency found"
openase ticket detail     $PROJECT_ID $TICKET_ID

openase workflow create   $PROJECT_ID --name "Codex Worker"
openase scheduled-job trigger $JOB_ID
openase project update    --description "Latest context"

openase api GET  /api/v1/projects/$PID/tickets --query status_name=Todo
openase api PATCH /api/v1/tickets/$TID --field status_id=$SID

openase watch tickets $PROJECT_ID

--jq '<expr>'              # JQ filter
--json field1,field2       # Select fields
--template '{{...}}'       # Go template

Both --kebab-case and --snake_case flag spellings are accepted.

Agent workers inherit environment variables from the workspace wrapper:

make hooks-install        # Set up git hooks (lefthook)
make check                # Run formatting + backend coverage checks
make build-web            # Build frontend assets + Go binary (does not refresh OpenAPI artifacts)
make build                # Build Go binary only (uses existing frontend)
make run                  # Run API server in dev mode
make doctor               # Run local environment diagnostics

make web-format-check     # Prettier formatting
make web-lint             # ESLint checks
make web-check            # Svelte type checking
make web-validate         # All of the above

make openapi-generate     # Regenerate api/openapi.json + TS types
make openapi-check        # Verify committed artifacts are up-to-date

make test                        # Go test suite
make test-backend-coverage       # Full backend tests + coverage gate
make lint                        # Lint changes since origin/main
make lint-all                    # Full lint suite

See LICENSE.

linux.do

OpenASE
Create the ticket. The agent does the rest.