What causes "Task ID is required" in eyaltoledano/claude-task-master?

Pass a positive integer string for a top-level task, e.g. id: '3'.

INPUT_VALIDATION_ERROR

INPUT_VALIDATION_ERROR

Error message

Task ID is required

What it means

expandTaskDirect parses the 'id' argument with parseInt and requires a truthy numeric task ID. Missing, non-numeric, or zero-resolving values produce this INPUT_VALIDATION_ERROR. Note parseInt returns NaN for non-numeric strings, and NaN/0 are both falsy, so any malformed ID fails here.

Source

Thrown at mcp-server/src/core/direct-functions/expand-task.js:84

				code: 'MISSING_ARGUMENT',
				message: 'tasksJsonPath is required'
			}
		};
	}

	// Use provided path
	const tasksPath = tasksJsonPath;

	log.info(`[expandTaskDirect] Using tasksPath: ${tasksPath}`);

	// Validate task ID
	const taskId = id ? parseInt(id, 10) : null;
	if (!taskId) {
		log.error('Task ID is required');
		return {
			success: false,
			error: {
				code: 'INPUT_VALIDATION_ERROR',
				message: 'Task ID is required'
			}
		};
	}

	// Process other parameters
	const numSubtasks = num ? parseInt(num, 10) : undefined;
	const useResearch = research === true;
	const additionalContext = prompt || '';
	const forceFlag = force === true;

	try {
		log.info(
			`[expandTaskDirect] Expanding task ${taskId} into ${numSubtasks || 'default'} subtasks. Research: ${useResearch}, Force: ${forceFlag}`
		);

		// Read tasks data
		log.info(`[expandTaskDirect] Attempting to read JSON from: ${tasksPath}`);

View on GitHub (pinned to c0c98d367c)

Solutions

Pass a positive integer string for a top-level task, e.g. id: '3'.
To expand a subtask, use the dedicated subtask expansion path/parameters rather than passing '3.1' here.
Sanitize the ID client-side: strip non-digits and verify parseInt > 0 before calling.
Check tasks.json to confirm the task ID exists (IDs are 1-based).

Example fix

// before
await expandTaskDirect({ tasksJsonPath, id: 'task 3' }); // parseInt -> NaN
// after
const num = parseInt('3', 10); // 3
await expandTaskDirect({ tasksJsonPath, id: String(num) });

Defensive patterns

Strategy: type-guard

Validate before calling

function normalizeTaskId(raw) {
  const n = parseInt(String(raw ?? '').replace(/[^0-9]/g, ''), 10);
  if (!Number.isInteger(n) || n <= 0) throw new Error(`invalid task id: ${raw}`);
  return String(n);
}

Type guard

function isValidTaskId(v) {
  const n = parseInt(v, 10);
  return Number.isInteger(n) && n > 0;
}

Try / catch

if (!isValidTaskId(id)) {
  return { success: false, error: { code: 'INPUT_VALIDATION_ERROR', message: 'Task ID is required' } };
}
const res = await expandTaskDirect({ tasksJsonPath, id });

Prevention

Sanitize LLM/user-supplied IDs down to bare digits before calling.
Treat subtask IDs ('3.1') as a different code path, not input to this validation.
Remember IDs are 1-based; never pass 0 or empty strings.
Show a task picker/list in UIs so IDs come from real data.

When it happens

Trigger: Calling expand_task with id omitted, id: 'abc' (NaN), id: '0', or a subtask-style ID like '3.1' whose parseFloat/parseInt handling yields an unexpected falsy value at this validation point.

Common situations: MCP clients sending the LLM-generated ID with formatting ('Task 3'), users attempting to expand subtasks via the plain task path, or UIs passing empty strings when no task is selected.

Related errors

AI-assisted analysis of eyaltoledano/claude-task-master@c0c98d367c (2026-08-29). Data as JSON: /api/errors/4530991f84430f40. Report an issue: GitHub.