"daytona code" fails with "exit status 255"

[bjornbyte]

Describe the bug
With daytona running in WSL on windows 11, after a reboot and "docker rm $(docker ps -aq)" running "daytona code" fails with the message "exit status 255".

To Reproduce
I don't know if this will reproduce it, but here's the setup I have and what I did today.

Setup last week (according to discussion in daytonaio/docs#229):

1. In WSL shell, install daytona using the command line from the docs:

(curl -sf -L https://download.daytona.io/daytona/install.sh | sudo bash) && daytona server -y && daytona

2. In WSL: daytona serve
3. In WSL shell 'daytona api-key generate`
4. In powershell: daytona profile add -a https://api-<SOME_GUID>.try-us.daytona.app -k <API_KEY> using values from the previous step
5. In powershell: daytona create
6. In powershell: daytona code

at this point everything was working nicely. I shut my machine down for the weekend. Today I wanted to go back to the workspace so I did:

• in powershell: daytona code

failed to check server health at: https://api-<GUID>.try-us.daytona.app/health. Make sure Daytona is running on the appropriate port"

no real surprise since I'd not started docker or daytona, so back to WSL:

1. sudo service docker start
2. daytona serve
   and I had a lot of (unrelated) docker container cruft sitting around so I also did docker rm $(docker ps -aq) then in powershell:
3. 'daytona code', which shows the expected project choice and after picking it prints `Opening the project from in VS code, waits for about five seconds and prints

time="2025-01-13T14:05:43-08:00" level=fatal msg="exit status 255"

Thinking it might be a powershell->WSL connection problem, I tried daytona code in a WSL window too and have a very similar experience ending with

FATA[0015] exit status 255

Desktop (please complete the following information):

• OS: Windows 11 with WSL
  ❯ uname -r
  5.15.167.4-microsoft-standard-WSL2
• Daytona Version: v0.50.0 on both

Additional context
daytona list lists all/both of my created projects as "RUNNING", but both give the same error when I try to open them with daytona code.
the daytona serve output when trying to open a project is:

INFO[1560] API REQUEST                                   URI=/health/ latency="12.165µs" method=GET status=200
INFO[1560] API REQUEST                                   URI="/workspace/?verbose=true" latency=8.249369ms method=GET status=200
INFO[1562] API REQUEST                                   URI=/workspace/3f457566fc6a latency="481.969µs" method=GET status=200
INFO[1562] API REQUEST                                   URI=/gitprovider/c631e6622721 latency="762.508µs" method=GET status=200
INFO[1563] API REQUEST                                   URI=/health/ latency="13.73µs" method=GET status=200
INFO[1563] API REQUEST                                   URI="/workspace/3f457566fc6a?verbose=true" latency=4.311016ms method=GET status=200
INFO[1563] API REQUEST                                   URI=/server/config latency="500.904µs" method=GET status=200
INFO[1563] API REQUEST                                   URI=/server/network-key latency=3.555639ms method=POST status=200

I'm not sure where to look for more details about the error.

[idagelic]

@bjornbyte I've managed to recreate this by restarting the PC while there were running workspaces in WSL. Please try running daytona start before running daytona code on these workspaces to get this to work.

The code/ssh commands are supposed to autostart stopped workspaces, but the workspaces are incorrectly perceived as "RUNNING".
This is due to improper project/workspace state management that has been improved/resolved in our upcoming overhaul/rework branch. We hope to release it some time this or next week - I will get back to this issue to notify you. Until then, I would appreciate it if you let me know if manually starting the desired workspaces works.

[bjornbyte]

It did not, but in this case I'm fairly certain that is because I likely deleted the containers that it turns out were important. Running daytona start gives me:

failed to start workspace my-project: Error response from daemon: No such container: 3f457566fc6a-my-project

I assume at this point I will need to delete and re-create the project.

[idagelic]

Right, in the case of having manually deleted the workspace container using the docker cli, recreating the workspace will be necessary