Cannot 'lk agent create' (v2.5.5 on Windows)

[DanMakingWithAI]

$ lk agent create
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
Using default project [metis]
Creating new agent
Using secrets file [.env]
Detected project type [python.pip]
open examples\python.pip.Dockerfile: file does not exist

I primarily use Git bash for windows. In cmd, I get:

>lk agent create
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
Using default project [metis]
Creating new agent
Detected project type [python.pip]
open examples\python.pip.Dockerfile: file does not exist

I notice that via cmd it doesn't seem to find/ask about .env files

I don't know the full location of the Dockerfile file it thinks it wants to open here, but I don't have that file in any place I can find.

I followed the winget instructions to install the LiveKit CLI

Agent runs fine but I can't deploy to cloud without a working lk

I get similar error messages with lk agent dockerfile except it doesn't bother to ask me to choose the project or .env (either via git bash or cmd)

(Given the filename match to the python.pip project type, I'll try uv since I've been meaning to for ages anyway, but that doesn't negate the issue.)

[rektdeckard]

Thanks for the report! Your main issue seems to be related to this: golang/go#45230
Apparently embedded filesystems (which we use to embed template dockerfiles) only work with Unix path separators. This code path is only taken if no Dockerfile exists, which is not something we were testing. I'll patch this ASAP.

As for why you don't see the env detection in Git Bash, did you get a prompt asking you for a file an selected [none], or did you simply not get asked?

[DanMakingWithAI]

Thanks! I might try and set up a quick distro in WSL2 to give it a go in there instead for now.

For lk agent create both in git bash and in cmd it asked me to choose a project. In git bash it also found and asked me to choose the .env file, whereas via cmd it did not.

For lk agent dockerfile in git bash and cmd, I'm asked about neither the project choice (looks like default is just used) nor any .env (it doesn't notice any)

Here's the output from those - I'm now using uv, but getting the same output - which you'd expect given your suspected cause:

Git bash:

$ lk agent dockerfile
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
Using default project [metis]
Detected project type [python.uv]
open examples\python.uv.Dockerfile: file does not exist

cmd:

>lk agent dockerfile                                                                       
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
WARNING: config file C:\Users\danie/.livekit/cli-config.yaml should have permissions 600
Using default project [metis]
Detected project type [python.uv]
open examples\python.uv.Dockerfile: file does not exist

[DanMakingWithAI]

Now I'm getting errors while installing the cli on WSL2 via curl -sSL https://get.livekit.io/cli | bash - trivial, but documentation should be evolved:

1. This script requires sudo (e.g. curl -sSL https://get.livekit.io/cli | sudo bash)
2. This script requires jq - I am getting main: line 40: jq: command not found (e.g. sudo apt install jq first)

But doing this all in WSL2 does indeed workaround the lk agent create issues. It could potentially be the fix to some other fairly transient exceptions being thrown and preventing uv run agent.py console and uv run agent.py dev from working properly in Windows, too - I noticed references to python files with unix in the name in the stack traces, which tipped me off that the switch to WSL2 might just prevent these from happening in future anyway. I've yet to see these in WSL2 in any case.

In case anyone is trying to follow along with this, it's worth noting that I didn't bother fixing the exception thrown due to a lack of PortAudio in WSL2 when attempting uv run agent.py console - I instead went straight to dev and that worked fine.

I also was getting a lot of registered workers from my local code tests that never received any jobs when I connected to the room and so nothing happened - but I know others have complained of similar issues sometimes and I assume that's a transient issue when testing with local code. I would guess that when LiveKit Cloud manages the agent lifecycle entirely on its own platform, it ought to be more robust. Now the agent is deployed to cloud I have yet to have this happen.