Manage coding agents across projects without losing the next decision

Updated 2026-10-23

Use a shared task dashboard when the difficult part is remembering which project needs a decision. Denly keeps each task, plan and review with its project while your existing coding agents execute on your machines.

Denly is a control plane for coding agents (Claude Code, Codex, Cursor, Grok Build, Antigravity) that run on your own machines using your vendor subscription or API key. It manages tasks, plans and reviews across projects; Git-backed tasks can open pull requests, while no-Git projects end with a review of local changes. Start with two independent projects and one machine. You do not need to set up a group runner just to manage them in one dashboard.

Follow a worked example.Storefront and Docs are sample projects, not customer results. The homepage illustrates the handoffs; the companion PR guide includes a runnable regression example. Playback length is not a measure of agent speed.

Set up two projects with a clear boundary

Install and authenticate a supported runtime on the computer that will execute the work. Follow the Quickstart to install the Denly CLI and sign in.
Add your storefront and documentation repositories as separate projects. For each, run the exact denly install <project-id> command shown by the dashboard.
Confirm each runner has reported online. Choose the runtime per project: they can use the same one, or different installed runtimes.
For this example, use a supervised flow with planning and PR review. Configure each project's own checks before starting real work.

Projects are uncapped on every plan. On Free, one active task runs per machine; approvals do not consume an execution slot. A docs PR can wait for you while the storefront task runs. Concurrent execution still depends on the plan, machine capacity and checkout locks.

A working session across Storefront and Docs

Situation	Your next decision	What stays with the task
Storefront: an empty cart is charged for delivery	Queue the bounded fix with acceptance checks.	The brief, selected runtime and project scope.
Storefront: the plan would also waive delivery for free items	Request the item-count condition and a free-item regression check, then approve the revised plan.	The plan and review conversation.
Docs: a delivery-rules PR from an earlier task is ready	Switch projects and inspect that PR when you have time.	The docs diff and its separate approval gate.
Storefront: a configured check failed	Open the error, inspect saved work, and continue it when recovery is available.	The failure and retained checkpoint, subject to recovery requirements.
Storefront: corrected checks pass and the PR is ready	Review the diff and evidence, then merge.	The reviewed task outcome. Docs still needs its own decision.

Step through the homepage example, then inspect the cart fix and run its checks. You can pause playback or jump between stages.

The useful habit is to return to the task that needs a decision, read its evidence, and leave the others in their current state. Switching projects does not approve a plan, restart a task or merge a PR.

What if you close the laptop or a run fails?

The dashboard can accept queued tasks while a runner is offline. Execution waits for an eligible machine to be awake and online. Check runner health before expecting progress; a task queued overnight is not evidence it ran overnight.

For failed work, Continue saved work resumes unfinished work when a valid retained checkpoint is available. Retry deliberately reruns a phase. Shared-workspace continuation stays on the original machine; changing machines requires supported, verified recovery. Read the recovery status before choosing an action.

When the change actually spans repositories

Two independent tasks can use separate project runners. A coordinated API-and-client change may instead need one task to see several projects. That is the reason to select a group runner.

Arrangement	Use it when	Boundary
Project runner	The task belongs to one project, which can contain multiple repositories.	Its project repositories and instructions.
Group runner	One task must coordinate changes across several projects.	The group's project checkouts; their locks prevent conflicting local work.
Personal folder	You want to organize the project switcher.	Organization only; it does not by itself widen a task's repository access.

Each project keeps its own checkout. A group runner does not require moving everything into one parent repository. Enroll only after you have access to all projects in the group; the organization guide covers setup and scope.

Several people can work on the same project

Members can have runners on different machines. Assigned claim scope routes tasks to the intended member; task claims and local checkout locks prevent competing execution. A single-project view is not a global one-person lock. Use task assignments and project permissions to make ownership explicit.

When a simpler tool is enough

If you only need to continue a Claude Code session from your phone, try its native Remote Control. It already connects mobile and web interfaces to local execution. Its documentation was checked on 23 October 2026.

Consider Denly when you want a consistent task queue and review workflow across projects, machines and supported runtimes. It adds an account, runner setup and a coordination service; it does not make an offline computer execute work or remove your AI provider's usage limits.