Bug: Environment variable names mismatch between documentation/code and CLI-generated config

[dercar2]

Bug: Environment variable names mismatch between documentation/code and CLI-generated config

Version: 3.4.0

Problem:
config-loader.js looks for environment variables with names:

• SSH_SERVER_{NAME}_KEYPATH (no underscore between DEFAULT and DIR)
• SSH_SERVER_{NAME}_DEFAULT_DIR

But CLI and documentation suggest different names:

• SSH_SERVER_{NAME}_KEY_PATH (with underscore)
• SSH_SERVER_{NAME}_DEFAULT_DIR (correct)

Code location: src/config-loader.js lines 139-142

keyPath: env[`SSH_SERVER_${match[1]}_KEYPATH`],
defaultDir: env[`SSH_SERVER_${match[1]}_DEFAULT_DIR`],

Suggested fix: Either:

1. Update code to accept both variants (backward compatible), OR
2. Update CLI to generate correct names, OR
3. Update documentation to clearly state the correct variable names

Workaround: Manually edit .env to use KEYPATH instead of KEY_PATH.

[bvisible]

Thanks for the report @dercar2! I dug into this and the situation is a bit different from what's described:

The code, CLI and documentation all use KEYPATH consistently:

• src/config-loader.js:139 reads SSH_SERVER_*_KEYPATH (no underscore)
• src/config-loader.js:223 (exportToEnv) writes SSH_SERVER_*_KEYPATH
• cli/lib/config.sh:194,245 (CLI generator) writes SSH_SERVER_*_KEYPATH
• README.md, INSTALLATION.md, CLAUDE.md, docs/DEPLOYMENT_GUIDE.md, docs/SEO.md, cli/README.md all document KEYPATH
• grep -r 'KEY_PATH' returns 0 hits in the entire repo

So the .env format has always been KEYPATH (no underscore). The likely source of confusion is the TOML format, which uses key_path (with underscore) — see src/config-loader.js:89 and the TOML examples in README.md. The two formats intentionally follow their respective ecosystem conventions (UPPER_SNAKE for env vars but compact for the variable name itself; lower_snake for TOML keys).

Could you confirm:

1. Which exact doc or CLI output suggested KEY_PATH to you? I want to fix it if there's a stale reference somewhere I missed.
2. Were you perhaps mixing TOML and .env conventions?

That said — your suggestion #1 (accept both variants for backward-compatibility / forgiveness) is a reasonable UX improvement and I'm happy to implement it. I'll leave this open while we sort out the doc question.