Feature Description
When retrieving a task via GET /api/tasks/:id or the MCP tasknotes_get_task tool, the response includes all frontmatter fields correctly but never includes the task body as the details field - even though details is defined in the TaskInfo type and is accepted as a write parameter by both POST /api/tasks and PUT /api/tasks/:id.
What I found
Both TasksController.getTask() and MCPService's tasknotes_get_task route through cacheManager.getTaskInfo(), which reads from Obsidian's metadataCache. Since metadataCache only indexes frontmatter, the note body is never read and details is never populated in the response.
update_task / PUT /api/tasks/:id does return details - but only when details was explicitly included in the update payload. It builds the response from { ...originalTask, ...updates }, so the body only appears if you just wrote it. There is no read path that surfaces existing body content.
I also verified that a minimal update (e.g. status only) correctly preserves the existing body in the file - so there is no data loss issue, just no way to read the body back.
Why this matters
My use case involves writing rich task bodies - checklists, subtask lists, acceptance criteria, research notes. Being unable to retrieve the body via the API or MCP means I have to fall back to reading the .md file directly via filesystem access, which is not always available depending on the environment the agent or tool is running in.
Workaround
Reading the .md file directly and splitting on the frontmatter block works, but only when the calling tool has direct filesystem access to the vault - which is not always the case.
Suggested fix
In getTaskInfo() (or as an optional parameter on the endpoint), a vault.read(file) call and splitFrontmatterAndBody() would populate details in the response. Both already exist in the codebase and are used today in TaskUpdateService. Including details by default on single-task GET requests seems reasonable; an include_body=true query parameter might be preferable for bulk list endpoints if the extra reads are a performance concern.
Happy to test or provide logs, if required.
Feature Description
When retrieving a task via GET /api/tasks/:id or the MCP tasknotes_get_task tool, the response includes all frontmatter fields correctly but never includes the task body as the details field - even though details is defined in the TaskInfo type and is accepted as a write parameter by both POST /api/tasks and PUT /api/tasks/:id.
What I found
Both TasksController.getTask() and MCPService's tasknotes_get_task route through cacheManager.getTaskInfo(), which reads from Obsidian's metadataCache. Since metadataCache only indexes frontmatter, the note body is never read and details is never populated in the response.
update_task / PUT /api/tasks/:id does return details - but only when details was explicitly included in the update payload. It builds the response from { ...originalTask, ...updates }, so the body only appears if you just wrote it. There is no read path that surfaces existing body content.
I also verified that a minimal update (e.g. status only) correctly preserves the existing body in the file - so there is no data loss issue, just no way to read the body back.
Why this matters
My use case involves writing rich task bodies - checklists, subtask lists, acceptance criteria, research notes. Being unable to retrieve the body via the API or MCP means I have to fall back to reading the .md file directly via filesystem access, which is not always available depending on the environment the agent or tool is running in.
Workaround
Reading the .md file directly and splitting on the frontmatter block works, but only when the calling tool has direct filesystem access to the vault - which is not always the case.
Suggested fix
In getTaskInfo() (or as an optional parameter on the endpoint), a vault.read(file) call and splitFrontmatterAndBody() would populate details in the response. Both already exist in the codebase and are used today in TaskUpdateService. Including details by default on single-task GET requests seems reasonable; an include_body=true query parameter might be preferable for bulk list endpoints if the extra reads are a performance concern.
Happy to test or provide logs, if required.