Feature request: extensible secret resolution in config dynamic strings (pass, 1Password, etc.)

[stig]

Currently ECA config supports ${env:VAR} to substitute environment variables in config values. This works well when paired with shell init sourcing, but for GUI apps (ECA Desktop) there's a gap -- they don't read shell init files, so you need a LaunchAgent or similar workaround.

It would be nice to support a generalised secret resolver pattern, e.g. ${cmd:pass show eca/my-key} or ${<backend>:<path>} where the backend is extensible.

Some concrete backends that would be useful:

pass (password-store)

"key": "${pass:eca/deepseek-key}"

Runs pass show eca/deepseek-key, GPG prompts via gpg-agent / pinentry-mac. One passphrase entry per session.

1Password CLI

"key": "${op://vault/Item/credential}"

Runs op read op://vault/Item/credential -- same syntax as op inject. Useful for users already on the 1Password ecosystem.

arbitrary command

"key": "${cmd:some-tool get xyz}"

Generic fallback -- runs the command, uses stdout.

The key benefit: no env var middleman, no LaunchAgents, no shell init timing races. The config file declares where the secret lives and ECA resolves it at load time, regardless of which editor/Desktop it's running in.

Implementation sketch:

• Support ${pass:<path>} mapping to pass show <path> (stripped trailing newline).
• Support ${op:<ref>} mapping to op read <ref>.
• On failure (non-zero exit / empty output), log a warning but don't crash.
• The pattern could be implemented as a plugin system for extensibility, or simply hardcoded for the most common backends.

[ericdallo]

@stig would support only cmd enough? I would like to avoid having too specific backends that few people use, if all can be solved with a cmd would be nice and easier to explain.

[ericdallo]

@stig I realized it would still not work since the PATH would not have homebrew bin paths and etc, the best would be to support cmd + auto add homebrew paths to the process as this will work for most macos users, will work on that

[stig]

@stig would support only cmd enough? I would like to avoid having too specific backends that few people use, if all can be solved with a cmd would be nice and easier to explain.

Yeah, supporting only cmd would be fine. I would prefer it to not be homebrew specific, however, as I don't use it. I use nixpkgs to install all my tools.

[ericdallo]

@stig i found a way to spawn a command to get user PATH and then run the command with that PATH, it's what we do in clojure-lsp and lots of other libs do as well (I hate macos hehe), it should work for all cases! I will push and do a release soon, if you could test it...