--session works on core commands but is rejected by plugin subcommands, so the documented way to run one command as another signed-in account doesn't work for plugins. DATUM_SESSION does work, which makes this look like the flag simply isn't passed through to the plugin process.
Reproduce
Two sessions for the same user, one per endpoint:
$ datumctl auth list
swells@datum.net api.staging.env.datum.net Active
swells@datum.net api.datum.net
A core command accepts the flag and reports the override:
$ datumctl whoami --session swells@datum.net@api.datum.net
Session: swells@datum.net@api.datum.net (from --session; the active session is unchanged)
A plugin subcommand rejects it:
$ datumctl assistant card --session swells@datum.net@api.datum.net
patch: unknown flag: --session
The environment variable is fine:
$ DATUM_SESSION="swells@datum.net@api.datum.net" datumctl assistant card
Patch (A2A protocol 1.0, v0.1.0)
...
Why it matters
datumctl --help advertises the flag as the way to do this:
Run one command as another signed-in account, leaving the active one as is:
datumctl get dnszones --session user@example.com@api.staging.env.datum.net
Someone following that with a plugin command gets an error that names the plugin (patch:) rather than datumctl, which points the reader at the wrong component. In practice it also pushes people toward switching their active session instead — which is exactly what the flag exists to avoid, and riskier when the two sessions are staging and production.
Suggested fix
Forward --session to plugins the same way DATUM_SESSION already reaches them. Failing that, having plugins accept and ignore it would at least avoid an error, though it would silently use the wrong account — worse than the current behaviour.
Found while validating a change across staging and production, where using the flag on the wrong environment is the mistake it's there to prevent.
--sessionworks on core commands but is rejected by plugin subcommands, so the documented way to run one command as another signed-in account doesn't work for plugins.DATUM_SESSIONdoes work, which makes this look like the flag simply isn't passed through to the plugin process.Reproduce
Two sessions for the same user, one per endpoint:
A core command accepts the flag and reports the override:
A plugin subcommand rejects it:
The environment variable is fine:
Why it matters
datumctl --helpadvertises the flag as the way to do this:Someone following that with a plugin command gets an error that names the plugin (
patch:) rather than datumctl, which points the reader at the wrong component. In practice it also pushes people toward switching their active session instead — which is exactly what the flag exists to avoid, and riskier when the two sessions are staging and production.Suggested fix
Forward
--sessionto plugins the same wayDATUM_SESSIONalready reaches them. Failing that, having plugins accept and ignore it would at least avoid an error, though it would silently use the wrong account — worse than the current behaviour.Found while validating a change across staging and production, where using the flag on the wrong environment is the mistake it's there to prevent.