Problem
Kimaki currently rejects --agent when sending to an existing thread/session:
kimaki send --thread <thread_id> --agent opencode --prompt '...'
Observed failure:
Incompatible options with --thread/--session: --agent
This came up while updating existing minion threads with follow-up instructions. The documented/session guidance still presents kimaki send --thread <thread_id> --prompt ... --agent <current_agent> as a useful pattern, but the CLI guard blocks it.
Why this may be obsolete
The agent for an existing Kimaki thread/session is already established by the thread/session runtime. Passing --agent on a follow-up send should either be harmlessly ignored, accepted only when it matches the existing agent, or treated as an explicit switch if the product supports that. Hard-rejecting the command creates a papercut and forces callers to special-case thread/session sends.
Chris's read: we probably do not need this guard anymore in the Kimaki plugin.
Desired behavior
Pick one small, explicit behavior:
- Preferred: allow
--agent with --thread/--session and ignore it when the destination already has an agent.
- Alternatively: allow it only if it matches the existing session agent, with a clear mismatch error.
- If agent switching is supported through slash commands only, keep that model but make
--agent absent-safe and non-fatal for existing destinations.
Acceptance criteria
kimaki send --thread <thread_id> --agent <agent> --prompt '...' no longer fails solely because --agent is present.kimaki send --session <session_id> --agent <agent> --prompt '...' no longer fails solely because --agent is present.- Existing new-thread behavior with
--agent remains unchanged.
- Tests or CLI coverage prove the accepted behavior for both
--thread and --session destinations.
- User-facing docs/help are updated so examples match actual CLI behavior.
Repro from today
Attempted command shape while updating existing minion threads:
kimaki send --thread 1511853155955245288 --agent opencode --prompt 'Update to your task: ...'
Result:
Incompatible options with --thread/--session: --agent
Removing --agent made the send succeed.
AI assistance
- AI assistance: Yes
- Tool(s): OpenCode (GPT-5.5)
- Used for: Drafting this issue from the observed Kimaki CLI failure and Chris's requested direction.
Problem
Kimaki currently rejects
--agentwhen sending to an existing thread/session:Observed failure:
This came up while updating existing minion threads with follow-up instructions. The documented/session guidance still presents
kimaki send --thread <thread_id> --prompt ... --agent <current_agent>as a useful pattern, but the CLI guard blocks it.Why this may be obsolete
The agent for an existing Kimaki thread/session is already established by the thread/session runtime. Passing
--agenton a follow-up send should either be harmlessly ignored, accepted only when it matches the existing agent, or treated as an explicit switch if the product supports that. Hard-rejecting the command creates a papercut and forces callers to special-case thread/session sends.Chris's read: we probably do not need this guard anymore in the Kimaki plugin.
Desired behavior
Pick one small, explicit behavior:
--agentwith--thread/--sessionand ignore it when the destination already has an agent.--agentabsent-safe and non-fatal for existing destinations.Acceptance criteria
kimaki send --thread <thread_id> --agent <agent> --prompt '...'no longer fails solely because--agentis present.kimaki send --session <session_id> --agent <agent> --prompt '...'no longer fails solely because--agentis present.--agentremains unchanged.--threadand--sessiondestinations.Repro from today
Attempted command shape while updating existing minion threads:
kimaki send --thread 1511853155955245288 --agent opencode --prompt 'Update to your task: ...'Result:
Removing
--agentmade the send succeed.AI assistance