José Almeida c0ce55ff9d fix: unblock terminals stuck on Connecting and heal task_environments (#769)
* fix(gateway): snapshot agentctl status and env id on session subscribe

Late-subscribing clients (page reload, task switch, WS reconnect) miss
the agentctl_ready and task_environment_id events fired during the
original launch. Without them, the env-routed shell terminal gate stays
stuck and the panel hangs forever on "Connecting terminal...".

- appendSessionStateMessage now carries task_environment_id so the
  frontend can seed environmentIdBySessionId for the active session.
- New appendAgentctlStatusMessage snapshots current agentctl readiness
  via a bounded Health probe and emits session.agentctl_ready /
  _starting to flip the client gate out of `undefined`.
- GetOrEnsureExecutionForEnvironment now publishes AgentctlStarting to
  mirror EnsureWorkspaceExecutionForSession and keep gate transitions
  monotonic.

* fix(web): drop shell-mode agentctl gate to unblock env-routed terminals

The shell terminal gate required agentctlStatus.isReady to flip to ready
before opening the WS, but that event may have fired before the client
subscribed (page reload, task switch, local-executor task switch). The
lazy create-on-terminal-connect path on the backend never fires either,
because the WS never opens — chicken-egg.

Backend env handler already waits for remote workspace readiness
server-side (waitForRemoteExecutionReadyWithTimeout), so the client
just needs the routing keys (env id + session id). Agent-mode terminals
still gate on readiness — the agent process must be wired before
passthrough I/O is meaningful.

Extract computeCanConnect helper to keep PassthroughTerminal under the
complexity ceiling.

* test: cover terminal-hang on subscribe snapshot and env-routed gating

Adds a backend unit test asserting appendSessionStateMessage carries
task_environment_id (the deterministic RED for the env-map seed bug),
plus E2E scenarios for the user-facing repros: cold load, kanban switch,
hard reload, sidebar switch, and a local-executor task switch that used
to poison the terminal for every subsequent task. Adds an
expectTerminalConnected helper to SessionPage to detect the
"Connecting terminal..." overlay.

* fix(repo): heal task_environments on boot and enforce one env per task

Live DB audit on the user's machine surfaced two corrupt-data classes that
manifest as the user-facing "terminal doesn't appear / Failed to fetch
terminals: 503" symptoms:

- 15 worktree-mode envs with worktree_path set but workspace_path empty.
  GetOrEnsureExecutionForEnvironment returns ErrSessionWorkspaceNotReady
  forever, the env terminal handler 503s.
- 3 tasks with two task_environments rows (race in lazy create — pairs
  4-6 s apart, both ready, distinct workspace_path).

healTaskEnvironmentWorkspacePaths backfills workspace_path = worktree_path
on the affected rows, and healDuplicateTaskEnvironments collapses each
duplicated task to its most recently updated env (re-pointing any sessions
still on the loser, then dropping the loser row).

ensureTaskEnvironmentTaskUniqueIndex adds a UNIQUE index on
task_environments(task_id) so a future race fails loud. Order matters:
heal must run first to drop duplicates before the unique index is created.

* fix(repo): reject empty workspace_path on worktree envs

The orchestrator's persistTaskEnvironment update branch previously left
workspace_path untouched, so an env created with empty workspace_path
would stay corrupt forever — terminals 503 with ErrSessionWorkspaceNotReady.

Tighten the repository boundary: CreateTaskEnvironment refuses worktree-mode
inserts without workspace_path, and UpdateTaskEnvironment refuses to clear
it back to empty. A future writer regression now fails loud at the boundary
instead of producing a row that breaks the env terminal handler.

* fix(executor): refresh paths on env update and dedupe by task

The persistTaskEnvironment update branch only mutated AgentExecutionID +
Status, so envs created earlier with an empty workspace_path stayed
permanently broken across launches. Refresh worktree + workspace fields
on update via a shared computeWorkspacePath helper used by both branches.

Concurrent launches for the same task previously raced inside this
function — each saw existingEnv == nil and each called
CreateTaskEnvironment, producing duplicate rows ~4-6 s apart in the live
DB. Hold a per-task mutex (mirroring sessionLocks) and re-fetch the env
inside the critical section so siblings reuse the row the first launch
persisted. The repo's unique index on task_environments(task_id) is the
durable guarantee; the lock just closes the window before the constraint
trips.

* test(repo): cover task_environments heal, validation, unique index

Repository unit tests for the new heal steps and writer guards:
- HealTaskEnvironmentWorkspacePaths_BackfillsEmpty / LeavesPopulatedAlone /
  Idempotent
- HealDuplicateTaskEnvironments_KeepsMostRecent (asserts session re-link to
  winner) / NoOpWhenSingle
- EnsureTaskEnvironmentTaskUniqueIndex_BlocksFutureDuplicates
- CreateTaskEnvironment_RejectsEmptyWorkspaceForWorktree /
  AllowsNonWorktreeWithEmptyWorkspace
- UpdateTaskEnvironment_RejectsClearingWorkspaceForWorktree

Tests live in the sqlite package so they can exercise the unexported
heal* helpers directly, mirroring how the boot path calls them.

* fix: address PR review feedback

- helpers.go: drop the 2 s blocking Health probe in
  appendAgentctlStatusMessage. sendSessionData runs in the WS read loop, so
  the probe was delaying every subscribe/focus ACK by up to 2 s. Use
  GetWorkspaceStream() != nil as the cached readiness signal — the stream
  manager only attaches it after Health succeeds, so its presence is a
  free, non-blocking proxy. Subsequent waitForAgentctlReady events still
  correct the snapshot if it picks the wrong one.

- manager_execution.go: publish AgentctlStarting INSIDE createExecution,
  before spawning waitForAgentctlReady. The previous order published it
  after createExecution returned, which let the goroutine race past on
  fast Health and deliver Ready before Starting. Drop the now-redundant
  publishes in EnsureWorkspaceExecutionForSession and the env lazy-create
  path.

- task_environment.go: replace the local executorTypeWorktree constant
  with models.ExecutorTypeWorktree (canonical) so a future rename of the
  type is caught by the compiler.

- base.go: heal_workspace_path now respects the kandev path layout —
  task-dir-mode envs (.../.kandev/tasks/<name>/<repo>) get
  Dir(worktree_path) as workspace_path, mirroring computeWorkspacePath
  in the orchestrator. Plain worktree mode unchanged.

- heal_test.go: tighten unique-constraint assertion to require a UNIQUE
  error string so the test fails loudly if a different DB error masks
  the constraint violation. Add task-dir-mode heal coverage.
2026-05-02 11:50:53 +01:00
2026-05-01 01:02:00 +01:00
2026-01-16 01:59:19 +00:00
2026-02-17 09:19:42 +00:00
2026-05-01 21:02:41 +01:00
2026-05-01 00:40:06 +01:00

Kandev

Manage and run tasks in parallel. Orchestrate agents. Review changes. Ship value.

Workflows | Roadmap | Contributing | Architecture | Discord

Kandev Demo

See all screenshots

What

Organize work across kanban and pipeline views with opinionated workflows and execute multiple tasks in parallel. Assign agents from any provider, and review their output in an integrated workspace - file editor, file tree, terminal, browser preview, and git changes in one place. Terminal agent TUIs are great for running agents, but reviewing and iterating on changes there doesn't scale.

Run it locally or self-host it on your own infrastructure and access it from anywhere via Tailscale or any VPN.

Open source, multi-provider, no telemetry, not tied to any cloud.

Vision

Humans stay in control. Define tasks, build agentic workflows with gates, review every change, decide what ships.

  • Review-first - Humans support production systems. We need to understand (yet) and trust the code that gets deployed.
  • Your workflow - Every team is different, and not every developer uses AI the same way. Define workflows once, share them across the team, and give everyone a consistent process for working with agents - regardless of experience level.
  • Remote agents - Running multiple agents on a large codebase can quickly saturate a local machine. The goal is a single control plane: offload execution to servers, orchestrate from anywhere, including your phone.

Features

  • Multi-agent support - Claude Code, Codex, GitHub Copilot, Gemini CLI, Amp, Auggie, OpenCode
  • Parallel task execution – start and manage multiple tasks from different sources simultaneously, boosting productivity with AI agents
  • Integrated workspace - Built-in terminal, code editor with LSP, git changes panel, embedded vscode and chat in one IDE-like view
  • Kanban task management - Drag-and-drop boards, columns, and workflow automation
  • Agentic workflows - Multi-step pipelines that mix-and-match agents per step - for example, Claude Code Opus to design a plan, GitHub Copilot Sonnet to implement it, and Codex GPT 5.4 to review the changes. See docs/workflows.md
  • Sub-tasks - Agents can spawn sub-tasks that resume from the parent task's session. Useful for splitting a task that has grown too big, or producing several PRs from the same starting point.
  • CLI passthrough - Drop into raw agent CLI mode for direct terminal interaction with any supported agent, leverage the full power of their TUIs
  • Workspace isolation - Git worktrees prevent concurrent agents from conflicting
  • Flexible runtimes - Run agents as local processes, in isolated Docker containers or in remote executors like sprites.dev
  • Session management - Resume and review agent conversations
  • Stats - Track your productivity with stats on the completed tasks, agent turns, etc

Supported ACP Agents

Agent Protocol
Claude Code ACP (@zed-industries/claude-agent-acp)
Codex ACP (@zed-industries/codex-acp)
GitHub Copilot ACP
Gemini CLI ACP
Amp ACP (amp-acp)
Auggie ACP
OpenCode ACP

All agents communicate via ACP (Agent Client Protocol). Some agents support ACP natively, while others use ACP adapter packages that bridge their native protocols. CLI Passthrough mode is also available for direct terminal interaction with any agent CLI. If your agent isn't supported yet, open an issue or submit a PR with the integration. See Adding a New Agent CLI for a step-by-step guide.

Bring your own TUI agents

There is support for running any agent as TUI inside a terminal. Just add the cli command in the agent profile settings and the task will start the agent inside a PTY terminal instead of using ACP.

Supported Executors

Executor Description
Local Process Runs the agent as a local process on the host machine
Docker Runs the agent in an isolated Docker container
Sprites Runs the agent in a remote cloud environment via sprites.dev

Each executor uses git worktrees for workspace isolation, preventing concurrent agents from conflicting.

Quick Start

npx kandev

This downloads pre-built backend + frontend bundles and starts them locally. The worktrees and sqlite db will be created in ~/.kandev by default. Should work on macOS, Linux, and Windows (WSL or native).

From Source

# Clone the repository
git clone git@github.com:kdlbs/kandev.git
cd kandev

# Start in production mode
make start

Prerequisites: Go 1.26+, Node.js 18+, pnpm, Docker (optional - needed for container runtimes)

High level architecture

graph LR
    UI[Web UI] --> Backend


        Backend["Backend (Orchestrator)"]


    Backend --> W1 & W2

    subgraph W1[Local Process]
        Agent1[Agent CLI] --- WT1[Worktree]
    end

    subgraph W2[Docker Container]
        Agent2[Agent CLI] --- WT2[Worktree]
    end

We also want to add support for these remote runtimes:

  • Remote SSH - run agents on remote servers over SSH, using docker or local processes with workspace isolation
  • K8s operator - run agents in a Kubernetes cluster, with auto-scaling and resource management.
Development

Project Structure

apps/
├── backend/    # Go backend (orchestrator, lifecycle, agentctl, WS gateway)
├── web/        # Next.js frontend (SSR, Zustand, real-time subscriptions)
├── cli/        # CLI tool (npx kandev launcher)
└── packages/   # Shared UI components & types

Prerequisites

  • Go 1.21+
  • Node.js 18+
  • pnpm
  • Docker (optional)

Running Dev Servers

# Start everything (backend + frontend with auto ports)
make dev

# Or run separately
make dev-backend    # Backend on :38429
make dev-web        # Frontend on :37429

Testing & Linting

make test           # Run all tests (backend + web)
make lint           # Run all linters
make typecheck      # TypeScript type checking
make fmt            # Format all code

Pre-commit Hooks

# Install pre-commit (https://pre-commit.com/#install)
pipx install pre-commit

# Install git hooks
pre-commit install

Comparison to Other Tools

There are a few similar tools in this space, and new ones appearing everyday. Here's what sets this one apart:

  • Server-first architecture - Not a desktop app. Runs as a server you can access from any device, including your phone. Start a task away from your computer and check in on it later.
  • Remote runtimes - Run agents on remote servers and Docker hosts, not just your local machine.
  • Multi-provider - Use Claude Code, Codex, Copilot, Gemini, Amp, Auggie, and OpenCode side by side. Not locked to one vendor.
  • CLI passthrough and chat - Interact with agents through structured chat messages or drop into raw CLI mode for full agent TUI capabilities.
  • Open source and self-hostable - No vendor lock-in, no telemetry, runs on your infrastructure.

Contributing

Contributions are welcome! Please read CONTRIBUTING.md before opening a PR.

See the issue tracker for open tasks, or join our Discord to chat with maintainers and other contributors.

Acknowledgments

Built with these excellent open-source projects:

Monaco Editor · Tiptap · xterm.js · dockview · CodeMirror · dnd-kit · Mermaid · Recharts · TanStack Table · Zustand · Shadcn/UI · Radix UI · Tailwind CSS

License

AGPL-3.0

Star History

Star History Chart
S
Description
Upstream mirror of https://github.com/kdlbs/kandev (main). Internal development and testing.
Readme 371 MiB
Languages
Go 58.3%
TypeScript 37.6%
HTML 1.9%
JavaScript 0.8%
Python 0.7%
Other 0.5%