The documentation insists on a detailed product description: the more detailed the source, the better the tasks come out. There is no hard requirement, though - an individual task can also be created by simply asking in chat.

When the implementation drifts from the plan, tasks are not rewritten by hand. There is a command that updates everything from a given task onward against a new input:

The --research flag brings in a separate research model, so the decision is made from current data rather than from what the model remembers.

Installation

The main route is as an MCP server in your editor. For Claude Code that is one command:

For Cursor, Windsurf and Q CLI the configuration is written by hand under the top-level key mcpServers; in VS Code that key is called servers and also needs "type": "stdio".

The command line installs separately and works with no editor at all:

Node.js 20 or later is required. Rules for specific editors can also be added after initialisation with task-master rules add.

The documentation separately asks you to put the MCP configuration in .gitignore, so the keys do not end up in the repository.

Three Models Instead of One

Three roles are configured: main, research and fallback - the last one steps in when either of the first two fails. The provider key has to live either in the MCP configuration or in .env, and the requirement is stated in capitals in both cases.

One key from the list is enough: Anthropic, OpenAI, Google Gemini, Perplexity, xAI, OpenRouter. Two options stand apart, needing no key at all: Claude Code (only the CLI has to be installed) and Codex CLI (OAuth through a ChatGPT subscription).

Models are switched by conversation rather than by editing files:

The research model is optional, but the documentation recommends it insistently - without it the --research commands lose their point.

There Are More Tools Than the README Says

Here is the part that matters to anyone counting context. The full MCP tool set eats a noticeable slice of the window, so selective loading through an environment variable exists.

The figures in that table come from the README, and two of the three disagree with the code. The tool registry in mcp-server/src/tools/tool-registry.js holds 44 entries, not 36. The standardTools array has 14 items, not 15 - and the comment beside it honestly says "14 most commonly used tools". Only the minimum matched: coreTools really is seven - get the task list, get the next one, get one task, change status, update a subtask, parse the product description, expand a task.

What that means in practice: the token estimates are understated by roughly a quarter, because they were computed for a set of 36 tools. If context is scarce for you, core mode is a real saving, but assume the full set costs more than advertised.

Tags as Contexts

A mechanism the neighbouring projects do not have: task lists can be kept separately per context - per branch, per feature, per experiment.

A tag is created straight from the current Git branch name, so task lists stop mixing across parallel work. Tasks move between tags, with or without their dependencies:

autopilot: The RED, GREEN, COMMIT Cycle

The newest part is a separate family of eight tools that walks a task through test-driven development.

autopilot_start creates a Git branch and stands up a workflow state machine. From then on the agent asks autopilot_next and gets not general advice but a specific next action, with the current phase and subtask. autopilot_complete advances the phase against test results, autopilot_commit records progress with metadata, autopilot_resume continues from a checkpoint, autopilot_abort cancels everything, autopilot_status shows the state.

The stated behaviour is enforcement of the RED, GREEN, COMMIT cycle: a failing test first, then the code, then the commit. The same operations exist in the command line as task-master autopilot start <id> and so on.

One caveat: the repository's docs/ directory says nothing about autopilot at all. It lives in the code and in the changelog, and the guide link in those same release notes points at a subdomain that currently does not respond - the last commit to the repository was literally titled "replace retired task-master.dev URLs". Working it out means reading the source or the documentation on the commercial site.

loop and Permissions

There is a task-master loop command that drives an agent through tasks unattended. How it works is worth knowing before you run it.

By default it invokes claude -p with the --dangerously-skip-permissions flag - the changelog states this outright as the choice for unattended execution. Docker isolation exists but is opt-in through a --sandbox flag and is off by default.

Progress accumulates in a file, and the release notes specifically warn you to delete it between runs so old context is not dragged into a new one. A --verbose flag shows the model's work in real time, --no-output does the opposite and excludes the full output from results to save memory. Combining --verbose with --sandbox is not allowed.

The Repository Has Gone Quiet

This has to be said plainly, because the decision depends on it.

The last commit to the main branch was 23 April 2026. The last release was 0.43.1 on 31 March 2026. Nothing has been published to npm since: the registry shows the same 0.43.1 plus a separate rc tag at 1.0.0-rc.1, published on 18 February 2026. In other words, the candidate for a first major release has been sitting still for six months.

The documentation, meanwhile, has moved. The README points not at docs/ but at tryhamster.com - the commercial platform Task Master became part of. The links for the quick start, the tool reference and the loop command all go there, and so does the pricing page.

The content of the last release is telling too. Version 0.43.1 consists of a single change: stop creating the hamster and ham shell aliases during project initialisation, and clean up any that already exist. The last thing the project managed to do was walk back its own branding.

None of this supports any conclusion about whether the project is abandoned - it works, version 0.43.1 is on npm and installs. But there is currently nothing to base an expectation of fixes in the open repository on.

What to Know in Advance

Concurrent access to tasks.json used to lose data. The project admits it outright: version 0.42.0 added cross-process locking, atomic writes, and stale-lock cleanup with a ten-second timeout, so several windows of the same editor do not overwrite the file behind each other. If yours is older, upgrade.

Task metadata has to be enabled separately. Tasks carry a free-form metadata field for your own data - ticket number, sprint, estimate. Editing it through MCP requires TASK_MASTER_ALLOW_METADATA_UPDATES=true in the server environment.

The repository's documentation directory lags behind the site. The twenty pages in docs/ describe the state as of spring; the current sections - autopilot, loop, team work - exist only on the commercial site.

Two MCP server implementations live side by side. The older JavaScript one in mcp-server/ and the newer TypeScript one in apps/mcp/; the tool registry pulls in both. The eight autopilot tools and four task tools come from the new one, the remaining thirty-two from the old.

Zero tools after installation is usually about keys. The README answers this in advance: restart the editor and check that the keys are configured correctly.

First-Encounter Mistakes

Planning to sell a product built around Task Master. The Commons Clause forbids it, and the ban extends to hosting and paid support.

Expecting an MIT badge on GitHub. It is not there and will not be - a licence with a condition attached is not classified automatically.

Trusting the token-cost table in the README. The registry holds 44 tools, not 36; the standard set has 14, not 15.

Running loop on a production repository without looking. By default that is an agent with no permission prompts and no sandbox.

Not clearing the progress file between loop runs. Old context will ride into the new run; the authors warn about it themselves.

Keeping the MCP configuration in the repository. It holds keys, and the documentation asks you to gitignore the file.

Looking for autopilot in the repository documentation. It is not there, only the code and the changelog.

Opening several editor windows on an older version. Before 0.42.0 that risked losing tasks.json.

To put it in one sentence: Task Master is useful precisely because the state of the work sits in a file you can open and read with your own eyes - but before installing it, read the licence and the date of the last commit rather than the README.

Sources

This article was checked against the eyaltoledano/claude-task-master repository (branch main) on 25 August 2026: the README, package.json, LICENSE, CHANGELOG.md, mcp-server/src/tools/tool-registry.js, the apps/mcp/src/tools tree, docs/licensing.md and docs/tutorial.md. The MCP tool count and the contents of each set were recounted from the registry in the code - they disagree with the table in the README. The dates of the last commit, the last release and the last npm publish were taken the same day through the GitHub API and the npm registry.

• GitHub: eyaltoledano/claude-task-master
• Documentation on the Hamster site
• Installation
• MCP tool reference
• The loop command
• Licensing
• The licence text
• The MCP tool registry
• The workflow guide
• Changelog
• Releases