Docker terminal state

[rbren]

Describe the bug
Currently, our DockerInteractive terminal loses some state. In particular, if the agent runs a cd command, the next command doesn't run inside that directory.

Steps to Reproduce

1. uvicorn opendevin.server.listen:app --reload --port 3000
2. websocat ws://127.0.0.1:3000/ws (in a second terminal)
3. send these messages:

{"action": "run", "command": "ls"}
{"action": "run", "command": "mkdir foo && cd foo && touch file.txt"}
{"action": "run", "command": "ls"}

Expected behavior

• output of second ls command shows file.txt

Actual behavior

• output of second ls command shows directory foo

Additional context
I'm not sure what other state we might be losing with docker's exec command. The only other one I can think of is exported environment variables.

Suggested solution
Two ways we could go here:

• Create a long-lived shell connection to the running docker container, e.g. via ssh
• Figure out cwd at the end of each exec, and use that as workdir for the next exec

[rbren]

CC @xingyaoww who pointed this out

[rbren]

Another data point: the agent keeps trying to use virtualenv, and then getting confused when it doesn't work 🙃

[yufansong]

I am little confused, I try the step locally in latest main branch. But when sending {"action": "run", "command": "ls"}, will trigger the code logic here and get NotImplementedError. what did I miss?

[xingyaoww]

@yufansong Thanks for bringing up the issue! We had some lengthy discussion about this yesterday -- basically we were thinking whether it make sense for us to support sending actions from the user's end at this early stage. We temporarily decided to remove the ability from the user for them to execute commands directly, so websocket might not be a good direction to reproduce this yet.

Here's another step to reproduce this issue:

1. at root directory: mkdir workspace
2. python3 opendevin/sandbox/sandbox.py -d workspace
3. ls
4. mkdir foo && cd foo && touch file.txt
5. ls

See this screenshot for more details:

[rbren]

Closing this in favor of #226