🦤 DodoToGo

DodoToGo is an interactive, day-drillable visual task board for GitHub Copilot and VS Code. It combines natural-language task management with a visual weekly board, persistent state, dependency tracking, and optional parallel-agent workflows.

Overview

• Manage a weekly todo board with natural-language requests in Copilot chat.
• Drill into Monday-Friday views, move work across the week, and track task status visually.
• Use the same board through the Copilot canvas surface or the companion VS Code webview panel.

Installation

Download dodotogo.vsix from the latest GitHub release, then install it with:

code --install-extension dodotogo.vsix

Copilot integration

DodoToGo registers the @todo, @dodo, and @togo chat participants and a local MCP server that exposes the todo_* tools. Ask Copilot to create, update, list, move, or complete tasks without leaving your current conversation.

Visual weekly board

Open DodoToGo from the Activity Bar or run DodoToGo: Open Full Screen from the Command Palette. The sidebar and full-screen views share the same task state.

Getting Started

You do not need Azure DevOps, the Azure CLI, or any Microsoft-internal tooling to use DodoToGo. A first-run setup wizard walks through the essentials and skips anything that is not applicable to your machine.

1. Install the extension (see Installation).
2. Open a workspace folder in VS Code (optional — it enables the git and worktree features; your board is stored in your home folder either way).
3. Click the DodoToGo icon in the Activity Bar. The setup wizard opens automatically the first time.
4. Pick an AI CLI when prompted. GitHub Copilot CLI and Claude Code are the supported public choices; the wizard preselects one that is already installed. (Agency Copilot is offered on Microsoft-internal machines only.)
5. Finish the wizard — the Integrations page is skipped when no integrations are available on your machine, which is the expected non-Microsoft path.
6. Create your first task with Ctrl+Alt+N (macOS Cmd+Alt+N), or ask @todo add a task for today in Copilot Chat.

The bundled local MCP server registers todo_create_task, todo_update_task, and the other todo_* tools with GitHub Copilot Chat automatically — no extra configuration is required.

You can replay the wizard any time via DodoToGo: Run Setup from the Command Palette.

Usage

Copilot chat

Interact with the board using natural language. DodoToGo maps requests to its MCP tools and persists each validated change.

Canvas interactions

• Toggle status directly from the task card.
• In ordinary views, drag to reorder tasks within a day or onto another day to move them.
• In Machine view, bucket drops request ownership changes instead of changing day, status, or priority.
• Delete tasks from the board.
• Use Start to jump a task into in-progress.

Day navigation

• Monday-Friday day selector
• Today button
• Previous/next week arrow buttons

Features

Status workflow

new → promised → planning → planned → in-progress → completed

Tasks waiting on dependencies or external work can be marked blocked.

Status color reference

Feature summary

State Persistence

• Primary state file: state.json at the board's storage root, alongside a days/ folder holding one file per day
• Default storage root: ~/.copilot/DodoToGo (%USERPROFILE%\.copilot\DodoToGo on Windows)
• Write strategy: write state.json.tmp, then rename into place
• Recovery: unavailable sync or versioned ownership metadata blocks unsafe writes; use supported diagnostics/recovery rather than resetting ownership evidence.

The storage root is resolved in this order: the DODOTOGO_HOME environment variable, then the Cloud Sync root when Cloud Sync is enabled, then the ~/.copilot/DodoToGo default. Opening a workspace folder does not change where the board is stored — it only affects git and worktree features.

Worktree boundaries

Read-only operations outside the assigned task worktree are permitted for task context with available, authorized tools: reading files, searching code, and inspecting Git history (for example, git log and git show) in the main checkout, another worktree, or another repository.

Crossing the worktree boundary alone does not require additional approval for read-only inspection. Existing access restrictions, content exclusions, security controls, and independent approval requirements still apply. If access is denied, do not bypass the restriction or retry through another tool.

When a task worktree is assigned, keep task files and outputs inside it. Do not create, modify, or delete task files outside it, or mutate another checkout's repository state for this task. Builds, tests, installs, formatters, output redirection, and Git mutations are not covered by this read-only allowance; inspect their side effects and keep task writes scoped to the assigned worktree and branch.

Existing authorization for task-scoped Git operations, such as staging and committing, is unchanged even when Git manages metadata in shared storage outside the worktree. This does not authorize direct edits to shared Git metadata or configuration, or changes to another task's branch or checkout.

Separately requested workflows retain only their existing, explicitly authorized output locations and approval gates; the read-only allowance authorizes none of their writes. Without an assigned task worktree, retain existing filesystem and workflow boundaries; do not infer a new write location.

Never read or write DodoToGo board state files directly; use todo_* MCP tools. Updated guidance applies to newly generated prompts and synced bundled skills; it does not override instructions already present in a running session or change tool permissions, task ownership, or worktree management.

Copy a task ID

Right-click a task and choose Copy, or focus its card and press Shift+F10 then Enter. Only that task's exact ID is copied, even when multiple tasks are selected. Completed, blocked, and other-machine tasks can also be copied without changing their data or ownership.

Task ID copied appears after the clipboard write succeeds. Paste into your CLI input normally; Copy does not send keystrokes or submit commands. Clipboard permission errors are shown on the board. A timeout means the copy could not be confirmed, not that the clipboard was necessarily unchanged.

The standalone canvas needs a secure browser context and clipboard permission. For terminals, use Copy, then paste. This feature does not add terminal drag-and-drop support; existing task-ID drag payloads are unchanged. See [the implementation plan and verification matrix](https://github.com/ahsi-microsoft/Dodo-ToGo-V2/blob/HEAD/<design/Improve Drag and Drop Features Plan.md>) for the current evidence and remaining native checks.

Cloud Sync (multi-machine via OneDrive)

Cloud Sync is opt-in. Sync runs entirely through your own OneDrive account and folder — DodoToGo operates no sync backend of its own and never receives your task data. Enable dodoToGo.cloudSync.enabled in VS Code and either set dodoToGo.cloudSync.root to a OneDrive-synced folder or leave it blank to auto-detect Windows %OneDrive%. Advanced users can set DODOTOGO_HOME to the desired board root; that environment variable is the low-level override used by spawned tools.

DodoToGo uses a one-owner-machine model: a task owned by another machine is read-only until ownership is released or the lease expires. Use Filter in the board header to control task visibility. Every view has two labeled sections, separated by a line, containing the buckets from the other two views. Choices are OR within each section, AND between sections: a task must match one included bucket in each section. Clearing Status or Priority hides every task; clearing selectable Machine options leaves this machine included, subject to the other section's filters. Click an enabled checkbox, label, or count to toggle it without closing the dropdown. Filters do not change task fields or ownership. Ownership leases default to 48 hours; use the todo_claim_task MCP tool (with force: true when the owning machine is offline), todo_request_ownership to move ownership, or todo_unclaim_task when the owning machine voluntarily gives a task back.

Filter choices are shared by dimension across navigation and reloads. Each view uses the other two dimensions:

Status includes all seven buckets: Completed, Blocked, In Progress, Planned, Planning, Promised, and New. It uses the same canonical status grouping as the Status renderer; a derived blocked badge does not move a task out of its actual status bucket. Priority includes P0-P3. Machine lists each known individual machine, including empty and offline machines, plus Un-Owned. Ownership recovery and Ownership unavailable appear when relevant; neither missing metadata nor recovery is inferred to mean Un-Owned or a confirmed owner. There is no aggregate Other Machines checkbox. Completed tasks obey selected machine filters just like unfinished tasks.

The current machine's exact machine/enrollment identity is labeled This Machine and permanently checked, disabled, and greyed out. The section order is Select all, This Machine, Un-Owned, then the other machines. Older saved exclusions cannot hide this local machine, but Status and Priority filters can still hide its tasks. Another enrollment of the same machine is not local. No local row is invented without an actual roster or task-ownership entry and a matching current identity.

Fresh preferences exclude Completed and Blocked wherever a Status section exists, and include all other statuses, priorities, and machines. Changing Status choices in Priority also updates Machine; changing Priority choices in Status also updates Machine; changing Machine choices in Priority also updates Status. Navigation does not save or switch filter profiles. Machine choices are stored by stable machine/enrollment identity, so renaming a machine or changing its presence does not reset them.

Shared preferences persist under todo-canvas-bucket-filters:v2:<dimension> for priority, status, and machine. Upgrade migration favors valid v1 choices from the saved active view when it exposes that dimension, fills missing choices from the other relevant view, then uses legacy defaults. Fallback source order is Status (kanban) then Machine for Priority choices, Priority then Machine for Status choices, and Priority then Status for Machine choices. Without saved choices, legacy remote hiding is honored only when explicitly true. Once shared v2 preferences are saved, they take precedence over v1 and legacy data.

The current view's own bucket dimension is not filtered, and its saved choices are retained rather than cleared. Controls and shortcuts cannot change unavailable dimensions. Collapsible buckets persist separately from filter choices. Machine collapse choices use stable machine/enrollment identity, and collapsed headers remain available as guarded ownership drop targets. A task can still be hidden by either of the other dimensions.

The Filter funnel icon sits after New Task, before the view toggle. Each section has its own Select all checkbox directly below its heading, followed by This Machine when present, then its selectable bucket rows; there is no top-level Select all. It toggles only that section's selectable options, leaving the pinned local machine and the other section unchanged. Checked and mixed states count only selectable options; if there are none, Select all is unchecked and disabled. Each bucket shows its deduplicated matching task count for the selected day before any filtering, including completed tasks in machine counts. Counts stay unchanged when a filter hides tasks. H toggles Completed only where the Status section exists. Alt+H toggles known remote machine choices together only where the Machine section exists; it does not toggle this machine, Un-Owned, recovery, or unavailable. Tab to Filter and press Enter or Space to open it and focus the first section's Select all; Tab visits that section's selectable buckets before the next section's Select all and selectable buckets, skipping the disabled local row. Space toggles a focused checkbox. Escape closes it and returns focus to Filter; clicking or tabbing outside dismisses it.

Filter changes apply immediately. If a preference cannot be saved, a warning remains until all outstanding choices are saved; later filter changes retry them. Dependency notices do not erase that warning and clear when host updates or navigation make them obsolete. Filter shortcuts are ignored while a dialog is open, and queued dependency focus resumes only after dialogs close.

Known limitations: OneDrive sync can take seconds to minutes, concurrency protection is best-effort while files are still syncing, and auto-detection is Windows-first.

Machine view

With Cloud Sync enabled, Machine replaces List in both VS Code and standalone canvas. A saved List selection, or disabling sync while Machine is selected, returns to Priority. Upgrade and restart all participating VS Code, canvas, and MCP runtimes, then finish the explicit Machine setup checklist.

Each enrolled machine has a labeled, consistently colored bucket, including machines without tasks. Un-Owned contains tasks without an active owner; ambiguous ownership appears separately as read-only Ownership recovery. Current day and status/visibility filters still apply. Dragging into a bucket, or using the keyboard ownership control, requests assignment, transfer, or release without changing day, status, priority, or order.

Offline destinations offer Wait, Force now, or Cancel. Requests stay pending until confirmed; a cancellation request is not a completed cancellation. Machine view filters by Priority and Status, not by its own machine buckets. Those choices are shared with the same filter dimensions in Priority and Status views. Bucket headers identify owners without repeating machine tags on every card. Right-click a card (or press Shift+F10) for Change owner; the card and empty-board context menus also expose Ownership requests and recovery for follow-up controls and errors. Ownership changes never start, stop, or migrate agents. Confirm running-agent and auto-pickup risks when prompted. After migration, use Machine controls for targeted handoffs; legacy ownership requests are quarantined, while ordinary queued task edits remain supported.

For a data-preserving rollback, set dodoToGo.machineView.newRequestsEnabled to false, or DODOTOGO_MACHINE_VIEW_NEW_REQUESTS_ENABLED=0 in standalone hosts. This pauses ordinary new requests and returns Machine to Priority without disabling sync, pending-operation controls, or ownership evidence. Use todo_machine_admin for bounded diagnostics; do not delete metadata or downgrade to an ownership-unaware build. See the troubleshooting and rollback guide and two-machine UAT checklist.

Model Configurations

• Open New Task or Edit Task, expand Optional Parameters, then use Model → ⚙ to register, edit, duplicate, delete, or set the default model configuration.
• A configuration stores a provider family plus a free-form model identifier. copilot covers both GitHub Copilot CLI and Agency Copilot; claude covers Claude Code. Copilot-family configs can also set reasoning effort and context tier, while Claude configs are currently model-only.
• Leaving a task on Default stores no explicit selection. At launch, DodoToGo applies the global default only when it is still valid and matches the active CLI family; an explicit task selection always wins and fails with an actionable message if it cannot be honored.
• dodoToGo.terminalExtraArgs still applies. Existing --model, --effort, or --context flags there beat the compatible global default, but an explicit task selection overrides only those managed flags and leaves every other extra arg untouched.
• Deleting a configuration clears it from every referencing task and clears the global default if it pointed there. Registration validates identifier shape only — it does not guarantee that your Copilot, Agency, or Claude account can actually use that model.

Architecture

Optional: Microsoft-internal tooling

These capabilities require Microsoft-internal accounts or tooling and are not part of the normal getting-started path. They stay hidden or disabled on non-Microsoft machines.

If you are on a non-Microsoft machine and want to be sure these paths stay out of the way, set dodoToGo.internalTooling to off in VS Code settings. Set it to on to force them on (Microsoft-internal machines usually get the correct answer from auto, the default). The list of domains treated as internal can be overridden with dodoToGo.internalCorpDomains.

Troubleshooting

If setup does not look right, DodoToGo writes a diagnostic log to the DodoToGo output channel: View → Output, then pick DodoToGo from the dropdown. It records the environment verdict (and the signals that produced it), the filtered integration list, which AI CLI was resolved, and the cloud-sync decision. Absolute filesystem paths are redacted by default so the log is safe to share.

Common non-Microsoft setup situations, all expected:

• No integrations offered. DodoToGo skips the Integrations page when nothing on your machine qualifies. Setup still completes.
• Agency Copilot missing. It is Microsoft-internal; on a public machine the AI CLI choice falls back to GitHub Copilot CLI or Claude Code.
• Azure CLI or ADO not configured. Both are optional. Setup proceeds and the ADO integration stays off.
• OneDrive not detected for Cloud Sync. A folder picker appears as the fallback so you can point Cloud Sync at any synced folder (or leave it off).

To re-run the wizard, use DodoToGo: Run Setup from the Command Palette.

Development

• Clone the DodoToGo repository.
• Run tests from the repository root: npm test (the script preloads a hermetic env helper — running node --test … directly is not hermetic and can be affected by ambient DODOTOGO_* variables)
• Run native browser checks with Node.js 22+ from the repository root: node .\src\tests\filter-browser-smoke.mjs "<browser executable>" covers filters, Machine buckets, ownership dialogs, and themes using synthetic snapshots.
• CI runs both suites on Windows with Node.js 24 for pull requests, main pushes, and merge groups.
• Package from the repository root: npm run package
• No external dependencies are required
• Implementation uses Node.js built-ins only

Configuration

• No configuration is required for local-only use
• The state file is created automatically on first use
• Theme is auto-detected from the OS color preference