For about a week after moving to the cloud, I could continue developing from my phone without opening my laptop. I began to wonder whether I would need WSL much at all. Then an ordinary package installation brought development to a halt.
npm could not reach the package registry. Investigation pointed to DNS resolution and the managed proxy connection. The problem was in the development environment's network path, not the application code. After several unsuccessful checks, I started WSL2 Ubuntu again. The same package registry was accessible from WSL.
One project, different workspaces
While investigating, I changed Cloud settings and started several new Codex task conversations. At first, I treated it like switching chat rooms. But the uncommitted changes in the earlier workspace did not automatically appear in a new workspace or in WSL, even with GitHub connected.
Starting new conversations did not establish the cause of the network failure. The network issue and code synchronization were separate problems.
When I inspected the WSL checkout, it was 46 commits behind GitHub's latest main. WSL also contained its own uncommitted changes. I needed to preserve both the Cloud-only work and the existing local edits.
Recovering uncommitted work in WSL
The Cloud workspace still held changes to 17 files. I preserved them in a separate workspace, verified that the files matched, checked for secrets, and transferred the changes to WSL without overwriting the original work.
I also kept the uncommitted files already present in WSL. The recovered changes applied cleanly against GitHub's latest main, and the automated checks reported:
- 34 server-side tests passed
- 47 web tests passed
- Production web build succeeded
I then committed the recovered changes on a separate development branch and created a pull request. The automated checks passed, but I held off merging into main or deploying to production until I could check the impact on the existing service.
Working between the two environments again
I moved to Cloud when WSL stopped. This time, I went back to WSL when work stalled in Cloud. When I first set up Cloud, I did not expect to reopen WSL so soon.
Checking the changes left in both environments took longer than I expected. If something similar happens again, I will probably start by checking which changes were actually committed in each workspace. For now, I plan to keep both Cloud and WSL available and use whichever one I need.