2.1.16 Battle Test (2.1.16)

Claude Code 2.1.16 introduced the Task Management System, a JSON-file-backed coordination primitive that gives orchestrators and subagents shared, mutable work state for the first time.

Epistemic status: changelog-derived, runtime-verified on 2.1.17. Tests conducted 2026-01-22.

What it introduces

2.1.16 replaced the monolithic TodoWrite (full-JSON-replacement semantics) with proper CRUD: TaskCreate, TaskUpdate, TaskGet, TaskList. Storage is flat JSON files at ~/.claude/tasks/{session-id}/{task-id}.json. Each task carries id, subject, description, activeForm, status, blocks, blockedBy, owner, and an open metadata field.

Dependency tracking uses blocks/blockedBy arrays. Completing a blocker auto-unblocks dependents; multi-level chains (A blocks B blocks C) work. The metadata field merges on update rather than clobbering, and no size limit was observed (1 MB payloads tested successfully). TaskGet does not surface metadata or dependency fields; raw file I/O is required to read them.

What the test found

The session constructed a 16-task DAG to battle-test the system against itself, then spawned three competing WORKER subagents to claim and complete tasks in parallel.

"Three workers racing for tasks: WORKER-001 and WORKER-003 correctly identified they lacked the tools and escalated. WORKER-002 just... figured it out. Read the JSON directly. Completed all 15 tasks."

All core features passed. The worker pool combo (combo-01-dag-execution) validated the full orchestration loop: orchestrator creates graph, subagents poll TaskList, claim via the owner field plus title-prefix convention, complete work, and dependencies unblock automatically. Metadata held audit-trail payloads across the session without loss.

One notable gap: the bt-tester subagent lacked TaskList/TaskUpdate tools, forcing it to fall back to direct file I/O. This worked, confirming that the official tools are convenience wrappers; the real primitive is the filesystem.

Failures and caveats confirmed by test:

• No cycle detection: circular blockedBy chains create permanent silent deadlock.
• No locking: concurrent writers use last-write-wins; the owner field is a convention, not a lock.
• No dependency removal: addBlocks has no inverse short of deleting the task.
• ID collision risk: external processes writing task JSON (e.g., hooks) can overwrite IDs that TaskCreate would have auto-incremented. Recommended mitigation: external creators use IDs 1000+.
• Skill-hook additionalContext injection: a PreToolUse hook in skill frontmatter fired but its output did not appear in Claude's context; settings.json hooks are the reliable path for context injection.

Why it matters

Before 2.1.16, an orchestrator received subagent output only as text and had to parse it back into state. After 2.1.16, both sides read and write the same JSON files. This enables orchestrated DAG execution as a first-class pattern and opens a channel for hooks and background processes to inject signals into Claude's awareness asynchronously via the task directory.

Caveats

The system is explicitly session-scoped; tasks do not survive session end. Cross-session persistence (via resume or symlink) was documented as a hypothesis but not tested. The design targets single-orchestrator coordination, not concurrent-writer production queues.