[bug] --config <profile> silently ignores stored credentials; exits 0 unauthenticated
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- node.js, typescript
- Domain
- cli
Research direction
Start by tracing the CLI's global --config option handling and the profile-loading path used by config show and auth status. Reproduce with a stored, non-active profile, then verify the commands load its credentials or fail with a non-zero error instead of printing generic output and exiting 0.
Written by the indexing model from the issue text.
Description
Environment
- CLI: bl 2.0.1
- Skill: 2.0.1
- Node: v26.9.0
- OS: macOS 26.6.2 (Darwin 25.6.0, arm64)
- Region: intl (ap-southeast-1)
Reproduce
# Precondition: profile "token-plan" is stored in ~/.bailian/config.json with
# api_key, base_url, workspace_id and a console token, but is NOT the active profile.
# 1. Address it with the documented --config global flag
bl --config token-plan config show
bl --config token-plan auth status
# 2. Activate the very same profile and repeat
bl config use --name token-plan
bl config show
bl auth status
Expected
--config <profile> selects and loads that profile's credentials, as documented
("Use a config profile from ~/.bailian/config.json"). Step 1 and step 2 should
report the same api_key / base_url / console gateway for the same profile.
Actual
Step 1 emits no config values at all — config show falls through to the
generic welcome/command list, and auth status reports the profile as
unauthenticated. Step 2 prints the credentials correctly:
api_key: [REDACTED]
base_url: https://token-plan.ap-southeast-1.maas.aliyuncs.com
workspace_id: [REDACTED]
Config: token-plan
API key (model): config [REDACTED]
Console gateway: config [REDACTED] (ap-southeast-1, international)
The profile is fully populated; only the --config addressing path fails to load it.
Full output
$ bl --config token-plan config show
>>> no key/value lines emitted; the generic command list is printed instead
$ bl --config token-plan auth status
>>> generic command list printed; profile reported as unauthenticated
Exit code: 0
The exit code is 0, so this is not even detectable as a failure by scripted
callers. An agent or CI wrapper that passes --config silently runs
unauthenticated (or against the wrong profile) rather than erroring out.
JSON error (if any)
None — the command exits 0 and emits no error object, so there is nothing for a
caller to branch on.
Already tried
bl update(1.28.0 → 2.0.1) andbl skill update; CLI and skill versions
aligned at 2.0.1 before reproducing- Reproduced on two different non-active profiles: the pre-existing
token-plan, and a freshly created profile produced by
bl auth login --console --console-site international --config <name> - Confirmed both profiles work immediately after
bl config use --name <profile>,
then break again when addressed via--config - Eliminated env-var precedence as a cause:
bl config showdocuments
flag > env > config, and the repro was run withDASHSCOPE_API_KEYfully
unset from the environment, so nothing was shadowing the stored key
Notes
- Frequency: always — deterministic, reproduced repeatedly on both profiles
- Invoked via: agent (Qwen Code) driving
blnon-interactively - Impact: multi-profile workflows are effectively unusable.
bl auth login --console --config <name>does create a fully populated
profile, but that profile cannot then be used via--config. The only way to
reach it isbl config use --name <name>, which changes global state and
disrupts whatever profile was in active use — so the flag's stated purpose
("Use a config profile") is not achievable. - Suggested fix: either make
--configload the named profile's credentials
as documented, or fail loudly (non-zero exit + explicit message) when the
named profile cannot be resolved. Silently exiting 0 with unauthenticated
behaviour is the worst of the two outcomes for automation. - Related observation (separate from this bug, reporting only in case it is the
same root cause):bl auth loginappears to resetworkspace_idon the
target profile back to the account's default workspace, even after it had been
set explicitly withbl config set --key workspace_id. We observed it revert
once and had to re-apply the value. - Possibly related open issue: #131 — same "config silently never takes effect"
class of symptom, different mechanism.
- Dominant language
- TypeScript
- Stars
- 333
- Forks
- 28
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 37
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelstudioai/cli
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelstudioai/cli#232 ·
-
[bug] bl update: darwin-arm64 binary ships invalid ad-hoc signature, killed by macOS (Killed: 9)Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
modelstudioai/cli#223 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
modelstudioai/cli#231 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
modelstudioai/cli#230 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
modelstudioai/cli#202 · 1 comment · 1 reaction ·
All issues in modelstudioai/cli
Similar issues
-
resources
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
railmapgen/rmg-palette#2445 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
danielmiessler/LifeOS#2242 ·
Maintainers usually reply within 5 days
-
good first issue hacktoberfest help wanted translation
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
callstackincubator/appduct#129 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100