I was just thinking this, but I just realized it is not specific to deployctl - anydeno installed global binaries end up here. See denoland/deno#2630. See also https://docs.deno.com/runtime/reference/env_variables/#special-environment-variables ($DENO_DIR environment variable).

Interestingly enough, I do have $DENO_DIR set as well.

Interestingly enough, I do have $DENO_DIR set as well.

You might have set it after installing deployctl?

Now that you mention that, I'm not sure. What could that mean? I did update my env not by just relogging but by rebooting, I had no .deno in my home but after a deployment it's there again!

Presumably the deployctl shim (exec deno run --allow-all --no-config 'jsr:@deno/deployctl' "$@" in a bash executable) performs an update check before running the deployment command, causing it to be recreated. Maybe your DENO_DIR isn't being exposed correctly to the shim? I'm not exactly sure why that would be, you might have to do some Googling and Stack Overflow-searching 😓

@uncenter I just re-read your comment and realized you were talking about the binary, not about state files created by deplyctl itself. No. deployctl saved credentials.json and update.json to ~/.deno/deployctl instead of ~/.cache/deno/deployctl.

I am referring to the binary shim in ~/.deno/bin/deployctl as well as ~/.deno/deployctl/update.json. (I don't seem to have a credentials.json though.)

Ah, I see, there is actually also an issue in this repository for deployctl specifically. I see what you mean.

I'll write up a pull request.