Description

After calling add_task with an explicit tag: parameter, the MCP response includes a "tag" field that shows the previous active tag (from use_tag() state), not the tag the task was actually added to. The task IS correctly added to the specified tag, but the misleading response causes agents/users to take incorrect corrective actions.

Steps to Reproduce

1. Call use_tag({name: "tag-a"})
2. Call add_task({title: "New task", tag: "tag-b"})
3. Response shows: {"data": {"taskId": 5, "message": "Success"}, "tag": "tag-a"} — note "tag-a"
4. Verify with get_task({id: 5, tag: "tag-b"}) — task exists correctly on tag-b

Expected Behavior

Response "tag" field should show "tag-b" (the actual target tag the task was added to).

Actual Behavior

Response "tag" field shows "tag-a" (the previous in-memory active tag). The task IS on the correct tag, but the response is misleading.

Impact

In our multi-agent environment, this caused an agent to call remove_task on what it thought was the wrong tag, accidentally deleting a completed task (#95) from an unrelated tag (paos-context-optimization). The response tag mismatch led to destructive corrective action on correct data.

Workaround

We verify all mutations via git commit message (git log --oneline -1 .taskmaster/tasks/tasks.json) which shows the actual tag, and read back the task on the intended tag before taking any corrective action.

Environment

• Task Master version: 0.43.0
• Node.js version: v24.13.0
• Operating system: Ubuntu 24.04
• IDE: Claude Code CLI