3.2.0 breaks caching system due to `circleci` lacking the `env` subcommand

[bitprophet]

Orb version:

3.2.0 (specifically as of the commits from #131) - can confirm dropping back to 3.1.0 avoids the issue

What happened:

circleci local execute name-of-job results in:

Error: unknown command "env" for "circleci"
Run 'circleci --help' for usage.
ERRO[0000] Exit with status 1 due to generic error       error="unknown command \"env\" for \"circleci\""

stemming from an internal script (the one for linking lockfiles) calling out to circleci env subst.

I wasn't able to determine exactly where this ends up running; or rather, why the circleci it calls is neither visible in eg docker run --rm -it cimg/python:3.8 (for any tags, eg behavior is same under cimg/python:3.13) nor matching the version in my localhost's environment (which is the latest possible circleci and does have circleci env subst).

I also haven't progressed to pushing my CI config updates to the server so I'm not sure if this issue occurs outside of circleci local.

Expected behavior:

Expected to actually run my task locally, as happens correctly with orb 3.1.0 and below, usually leading to errors that are actually my fault 😂

Additional Information:

Not super likely to matter but my execution environment is Arch Linux pinned to a 2024-ish archive repo. my circleci CLI version is 0.1.32638+2bfc35c (release).

[bitprophet]

I turned up a presumably related issue in the CLI's own repo: CircleCI-Public/circleci-cli#1017 - so it's plausible this one should get marked as a duplicate of that, though it got (seemingly erroneously?) closed.

If the comments there are to be believed, "the CLI's container's copy of itself is too old" isn't easily fixable, which might mean the right fix here is to not use the env subcommand at all. (But it's still unclear to me how widespread this is; may be limited purely to circleci local which, while incredibly useful, is probably only used by a fraction of the userbase.)

[marboledacci]

Hi @bitprophet as you have pointed out, the problem is on the CLI. It does inject an old version of the agent into the docker container when doing local executions. We are aware of the problem, and the team in charge of the CLI is working on a solution.