Summary
lk agent deploy invokes getAgentID() which reads cmd.String("id"), but the deploy subcommand does not register the --id flag in its Flags slice (unlike status, restart, rollback, update-secrets, and config, all of which do register it).
As a result, lk agent deploy --id CA_XXX fails at flag parse time with flag provided but not defined: --id, and the cmd.String("id") call inside getAgentID is effectively dead code for the deploy path.
Source references
In cmd/lk/agent.go, the deploy command's Flags slice contains:
Flags: []cli.Flag{
secretsFlag,
secretsFileFlag,
secretsMountFlag,
silentFlag,
regionFlag,
ignoreEmptySecretsFlag,
skipSDKCheckFlag,
agentPrebuiltImageFlag,
agentPrebuiltImageTarFlag,
},
No idFlag(false), unlike the nearby commands:
status -> idFlag(false)
restart -> idFlag(false)
rollback -> idFlag(false)
update-secrets -> idFlag(false)
config -> idFlag(false)
Yet deployAgent calls:
agentId, err := getAgentID(ctx, cmd, workingDir, tomlFilename, false)
and getAgentID does:
agentID := cmd.String("id")
if agentID == "" {
// fall back to livekit.toml
...
}
So getAgentID tries to honor a flag the deploy command never exposes to the user.
Impact
Deploys must always go through a livekit.toml file -- either located in the working directory or specified via --config <path>. There is no CLI-flag-only path.
This blocks workflows where:
- Agent IDs are stored in a secrets manager (Doppler, Vault, AWS Secrets Manager, etc.) and injected as environment variables at deploy time.
- Credentials come from
LIVEKIT_URL / LIVEKIT_API_KEY / LIVEKIT_API_SECRET env vars (which loadProjectDetails already supports).
- The repository does not commit per-environment
livekit.*.toml files.
The only current workaround is generating a temporary livekit.toml at deploy time and passing it via the global --config flag -- an extra indirection for what should be a single CLI flag.
Proposed fix
Add idFlag(false) to the deploy command's Flags slice. No other code changes are required -- getAgentID() already reads cmd.String("id") as its first resolution step, with the existing fallback to livekit.toml preserved.
Flags: []cli.Flag{
secretsFlag,
secretsFileFlag,
secretsMountFlag,
silentFlag,
regionFlag,
ignoreEmptySecretsFlag,
skipSDKCheckFlag,
agentPrebuiltImageFlag,
agentPrebuiltImageTarFlag,
idFlag(false), // <-- add this
},
Combined with the existing env-var-based auth (LIVEKIT_URL, LIVEKIT_API_KEY, LIVEKIT_API_SECRET), this would enable fully non-interactive deploys without any livekit.toml on disk:
LIVEKIT_URL=wss://my-project.livekit.cloud \
LIVEKIT_API_KEY=... \
LIVEKIT_API_SECRET=... \
lk agent deploy --id CA_MyAgentId --skip-sdk-check
Related
Summary
lk agent deployinvokesgetAgentID()which readscmd.String("id"), but thedeploysubcommand does not register the--idflag in itsFlagsslice (unlikestatus,restart,rollback,update-secrets, andconfig, all of which do register it).As a result,
lk agent deploy --id CA_XXXfails at flag parse time withflag provided but not defined: --id, and thecmd.String("id")call insidegetAgentIDis effectively dead code for the deploy path.Source references
In
cmd/lk/agent.go, thedeploycommand'sFlagsslice contains:No
idFlag(false), unlike the nearby commands:status->idFlag(false)restart->idFlag(false)rollback->idFlag(false)update-secrets->idFlag(false)config->idFlag(false)Yet
deployAgentcalls:and
getAgentIDdoes:So
getAgentIDtries to honor a flag the deploy command never exposes to the user.Impact
Deploys must always go through a
livekit.tomlfile -- either located in the working directory or specified via--config <path>. There is no CLI-flag-only path.This blocks workflows where:
LIVEKIT_URL/LIVEKIT_API_KEY/LIVEKIT_API_SECRETenv vars (whichloadProjectDetailsalready supports).livekit.*.tomlfiles.The only current workaround is generating a temporary
livekit.tomlat deploy time and passing it via the global--configflag -- an extra indirection for what should be a single CLI flag.Proposed fix
Add
idFlag(false)to thedeploycommand'sFlagsslice. No other code changes are required --getAgentID()already readscmd.String("id")as its first resolution step, with the existing fallback tolivekit.tomlpreserved.Combined with the existing env-var-based auth (
LIVEKIT_URL,LIVEKIT_API_KEY,LIVEKIT_API_SECRET), this would enable fully non-interactive deploys without anylivekit.tomlon disk:Related
livekit.tomlrequirement.