SafetyCard Request a review

Task Master (claude-task-master)

AI task-management system for coding agents, used as an MCP server in editors such as Cursor and Claude Code or as a CLI.

github.com/eyaltoledano/claude-task-master · 2026-10-05 · c0c98d3

Defense-in-depth score

2.0 / 10

Task Master runs with your full user authority and every provider API key you give it, and it loads project configuration and .env files from the workspace without asking, so an untrusted repository can change which model provider and endpoints it uses. Telemetry is on by default and records prompts and responses. Tool annotations are accurate, but there is no path containment, isolation or audit record.

Safest setup

Task Master labels every tool as read-only or destructive and keeps its default models on API providers, but it runs with your full user authority, trusts whatever configuration the project holds, and has no isolation, path containment or spend limit of its own. The safest setup narrows the keys and tools it gets, keeps your editor's approval in the loop, and builds containment around it yourself.

SetupHowWhat it gives you
Dedicated, low-limit keysGive the MCP server only the key for each provider you use, each a dedicated key with a spending limit set at the providerSpend and account reach stop at what the provider allows, whatever the session does C1
Per-call approvalKeep your editor's approval prompt on for tools marked destructiveHintA person sees each write to task files, config or git before it runs C2
Only the tools neededSet TASK_MASTER_TOOLS to core or a comma-separated list of the tools you useThe model sees fewer write, git and research tools C3
API model providersKeep the default anthropic and perplexity providers for the main and research rolesModel calls stay API requests, with no agent CLI started on your machine C4
Telemetry offSet anonymousTelemetry to false in the global section of the project's Task Master configPrompts, responses and tool activity stay off the third-party telemetry service C8
Reviewed project configurationUse Task Master in projects whose .taskmaster configuration and .env files you wrote or have readProviders, endpoints and provider settings come only from you C6
Task data under version controlCommit the .taskmaster directory before bulk or destructive task operationsA way back from a wrong overwrite or deletion of task data C2
Its own container or VMRun the editor session with Task Master in a container or VM whose network reaches only your model providersFile reads, writes and outbound requests stay inside a boundary you set C5

Approving with confidence

  • Read each prompt and approve calls one at a time; a research call can attach local files to its request.
  • A models call changes which provider and endpoint later calls use, so approve it when you asked for that change.

Handling data

  • Tasks and research notes are built from model output, PRDs and web results; read new tasks before your agent acts on them.
  • Autopilot workflows append an activity log under your home directory; store it like the projects it covers.

Key gaps (3)

  1. Workspace configuration and .env files can change model providers, endpoints and provider settings with no trust decision. C6 · Memory, context & configuration integrity
  2. Agent-CLI providers run on the host as the same user with the full environment and no isolation. C4 · Code-execution isolation
  3. Launched provider CLIs are unverified and receive every provider key in the environment. C7 · Third-party extensions

Criteria

C1 Identity & least privilege

0.05 / 1.00

Task Master runs as a local stdio process with the operator's full user authority and whatever provider API keys are placed in the MCP environment or a project .env file. Nothing narrows that authority: tools accept any absolute project directory, and spawned provider CLIs inherit the whole environment. There is no per-tool or per-request credential scoping. The keys it holds are LLM-provider keys, so the damage is mostly spend and local file changes rather than access to production systems.

C2 Approval gates

0.45 / 1.00

As an MCP tool server, Task Master leaves approval to the host but labels its tools: every tool carries a read-only or destructive hint, and reads and writes are separate tools. There are no previews or dry runs for destructive operations and no server-enforced read-only mode. Writes are mostly to task files, but some tools overwrite files at caller-chosen paths or create git commits of all changes, with no undo of their own.

C3 Tool & action scoping

0.45 / 1.00

Tools are narrow task-management operations with typed zod schemas, which keeps designed use small. Path arguments are not contained: the project root, research file paths and the parse_prd output path all accept any absolute path. The default loads all tools, including write, git and network-backed research tools, though tool groups can be selected with an environment variable.

C4 Code-execution isolation

0.00 / 1.00

With the default Anthropic API provider, Task Master runs no model-written code. It also ships providers that launch coding-agent CLIs (Claude Code, Codex, Gemini CLI, Grok CLI), and the models tool lets the host model switch to them. Those CLIs run on the host as the same user with the full environment, including every API key, and Task Master adds no isolation around them.

C5 Untrusted input blast radius

0.13 / 1.00

Task Master turns PRDs, project files and Perplexity web research into tasks that the host coding agent then reads and follows, with nothing marking which text came from untrusted sources. Responses wrap data in a JSON envelope with version and tag metadata, but task content carries no provenance. Assume a hijacked host: it can send any readable file to the research provider or point model calls at another endpoint through the models tool, but destructive changes are limited to task data and git commits.

C6 Memory, context & configuration integrity

0.10 / 1.00

Task Master keeps tasks, research notes and settings as project files that the host agent reads back in later sessions, and the task text it stores is built from model output, PRDs and web research. It loads the project's .taskmaster configuration and .env files from the workspace on every call without any trust decision, and those files choose the model provider and security-relevant endpoints and settings. Nothing validates or tags what is persisted.

C7 Third-party extensions

0.07 / 1.00

Task Master does not install plugins, but its agent-CLI providers launch whatever claude, codex, gemini or grok binary is on the user's PATH, with no version pinning or verification. Project configuration or the models tool can switch to these providers without a separate consent step. The launched CLI runs as the same user with the full environment.

C8 Secrets & sensitive-data protection

0.20 / 1.00

Provider keys come from the MCP environment or a project .env file and are held in process memory. Anonymous telemetry to Sentry is on by default and, as the changelog documents, records AI prompts and responses and MCP tool interactions, with default PII sending enabled. Error-message redaction exists only on the CLI path. A stored Hamster session, if the user logs in, is written with owner-only permissions.

C9 Audit & traceability

0.25 / 1.00

Task Master writes no audit record of its own for most tool calls; it sends log lines to the host over MCP and to stderr. The autopilot workflow appends structured events to an activity.jsonl file under the user's home directory, which covers only that workflow. Sentry spans are telemetry, not an audit trail.

C10 Limits & kill switch

0.33 / 1.00

Each model call has a per-role token limit and at most two retries, research file context is capped at 50KB, and the Grok CLI provider has a timeout that kills the process. There is no cost ceiling and no limit on how many model calls a bulk operation such as expand_all makes. Defaults can be raised from project configuration.