Summary
The launcher's argument parser hard-errors on unknown commands but silently ignores any unknown token that starts with -. Every flag the launcher doesn't recognize simply vanishes: it is neither an error nor forwarded to the claude invocation the launcher builds.
Where
LifeOS/install/LIFEOS/TOOLS/lifeos.ts, main() parser, default case (lines 748-753 on current main):
default:
if (!arg.startsWith("-")) {
// Might be an unknown command
error(`Unknown command: ${arg}. Use 'k help' for usage.`);
}Unknown words (k foo) exit loudly with "Unknown command", but unknown flags (k --foo) fall through the switch with no action at all.
Why it bites
The launcher wraps the real CLI, so it's natural to assume claude-native flags pass through. They don't, and nothing tells you:
k -r --fork-session opens the resume picker but drops --fork-session, so you continue the ORIGINAL session while believing you're working in a fork. That one is state-mutating: divergent work lands in the session you meant to preserve.k --continue, k --model <id>: silently dropped.- Typos are inconsistent with the command path:
k --locl silently launches with default behavior, while the equivalent bad command (k locl) errors loudly.
- The file's own comment block advertises a
--dangerous flag that the parser never implements, so even the launcher's self-documented flag is swallowed. That documentation divergence is filed as its own issue to keep this one about parser policy.
Suggested fix
Two complementary changes:
- Hard-error on unknown dash-flags, mirroring the existing unknown-command behavior:
error("Unknown flag: " + arg + ". Use 'k help' for usage."). This kills the silent-typo class.
- Add an explicit
-- passthrough: everything after a literal -- is appended verbatim to the claude argv in cmdLaunch(). That gives full access to claude-native flags (k -r -- --fork-session) without the launcher having to mirror the whole upstream flag surface forever.
Auto-forwarding unknown flags would also work, but then a launcher typo is indistinguishable from an intentional claude flag. The error-plus--- combination keeps both safety and capability.
Happy to PR this if the approach sounds right.
Summary
The launcher's argument parser hard-errors on unknown commands but silently ignores any unknown token that starts with
-. Every flag the launcher doesn't recognize simply vanishes: it is neither an error nor forwarded to theclaudeinvocation the launcher builds.Where
LifeOS/install/LIFEOS/TOOLS/lifeos.ts,main()parser, default case (lines 748-753 on currentmain):Unknown words (
k foo) exit loudly with "Unknown command", but unknown flags (k --foo) fall through the switch with no action at all.Why it bites
The launcher wraps the real CLI, so it's natural to assume claude-native flags pass through. They don't, and nothing tells you:
k -r --fork-sessionopens the resume picker but drops--fork-session, so you continue the ORIGINAL session while believing you're working in a fork. That one is state-mutating: divergent work lands in the session you meant to preserve.k --continue,k --model <id>: silently dropped.k --loclsilently launches with default behavior, while the equivalent bad command (k locl) errors loudly.--dangerousflag that the parser never implements, so even the launcher's self-documented flag is swallowed. That documentation divergence is filed as its own issue to keep this one about parser policy.Suggested fix
Two complementary changes:
error("Unknown flag: " + arg + ". Use 'k help' for usage."). This kills the silent-typo class.--passthrough: everything after a literal--is appended verbatim to theclaudeargv incmdLaunch(). That gives full access to claude-native flags (k -r -- --fork-session) without the launcher having to mirror the whole upstream flag surface forever.Auto-forwarding unknown flags would also work, but then a launcher typo is indistinguishable from an intentional claude flag. The error-plus-
--combination keeps both safety and capability.Happy to PR this if the approach sounds right.