Historical task deletes instead of being open on a fresh start

[nonsleepr]

App Version

v3.19.5

API Provider

LiteLLM

Model Used

N/A

🔁 Steps to Reproduce

Seems to be a resurrection of #1295.

Steps to reproduce:

1. Talk to Roo (create a task)
2. Close VS Code
3. Open Dev Container
4. Return to Roo and click on the old task
5. Observe task disappearance.

Dev Container seems to be what causes it.
Notably, if new task is created first, historical tasks open just fine (sometimes).

💥 Outcome Summary

Expected to open a task, ended deleting it.

📄 Relevant Logs or Errors (Optional)

Found the following error message in the Extension Host:

2025-06-09 22:50:08.135 [error] Error: Task not found
    at t.getTaskWithId (/home/vscode/.vscode-server/extensions/rooveterinaryinc.roo-cline-3.19.5/dist/extension.js:4700:5959)
    at t.showTaskWithId (/home/vscode/.vscode-server/extensions/rooveterinaryinc.roo-cline-3.19.5/dist/extension.js:4700:6069)

[dosubot]

Hi @nonsleepr! I'm Dosu and I’m helping the Roo-Code team.

I couldn't find any documentation or release notes that mention issue #1295, task deletion, or changes in task handling for Dev Containers in v3.19.5. The available docs only describe general task management and stack handling, but nothing specific to this bug or its triggers in Dev Containers or with LiteLLM as a provider. If you have more details about #1295 or any custom setup, sharing those might help narrow down the root cause.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[daniel-lxs]

This appears to be a storage path inconsistency issue that manifests specifically in Dev Container environments. The problem likely stems from the getTaskWithId method's aggressive cleanup behavior when task files cannot be located.

When a user clicks on a historical task, the system first checks if the task exists in taskHistory global state, then verifies the corresponding API conversation history file exists on disk. If the file check fails, it automatically deletes the task from state and throws "Task not found". In Dev Container environments, the globalStorageUri.fsPath used to construct task directory paths may point to different locations than where files were originally stored, causing legitimate tasks to be incorrectly identified as missing and deleted.

The existing comment on line 1140 acknowledges this known issue: "FIXME: this seems to happen sometimes when the json file doesnt save to disk for some reason". A potential solution would involve either making file path resolution more robust for containerized environments, or modifying the cleanup logic to avoid automatic deletion when files are temporarily inaccessible - perhaps implementing a retry mechanism or requiring user confirmation before permanent deletion.

[MuriloFP]

Seems to have been fixed by #4733.

Please feel free to re-open if it's still an issue.