[Feature]: `aioncore session create` and `session clear` — the agent-facing CLI can talk to conversations but cannot open or reset one

[mrjjstudio]

Use case

One conversation acts as an orchestrator. It dispatches work to other conversations with aioncore session send-message, and that part works well today.

What it cannot do:

• Open a fresh conversation for unrelated work.
• Reset a conversation whose context has gone stale.

Both require a human to switch to the desktop app and click. That breaks unattended automation at exactly the point where the agent is otherwise self-sufficient: it can delegate, but it cannot manage the lifecycle of what it delegates to.

What the CLI exposes today

agent-facing-session-cli:

• session capabilities
• session list
• session send-message

agent-facing-config-cli, conversation-adjacent:

• config conversation rename
• config cron jobs … and config cron current … — schedule a message into an existing conversation

The three-command session contract is hardcoded in
crates/aionui-app/src/commands/session_capabilities.rs —
commands lists exactly capabilities, list, send-message. There is no create, clear, delete, or compact anywhere in the agent-facing surface.

The backend can already do this

#772 (merged, from #770) added POST /api/conversations/{id}/fork, which creates a new conversation with a workspace, an agent binding, and lazy backend-session materialization.

So conversation creation already exists server-side, with the hard parts solved. What is missing is the CLI surface over it.

Proposed shape (minimal)

session create   # stdin: { workspace, agent (or assistant_id), name? }  -> { conversation_id }
session clear    # stdin: { conversation_id }

• create returns the new conversation id so the orchestrator can immediately send-message to it.
• clear resets an existing conversation's context in place, keeping its id — so scheduled cron jobs and any stored id stay valid.

clear discards conversation state and cannot be undone. It should be marked accordingly in the capability contract. The config CLI already has this concept: CommandDescriptor carries a destructive flag, and config cron jobs delete sets it (config_capabilities.rs:138). The session contract currently has no equivalent field, so one would need adding there.

Naming and exact input fields are open — the request is the capability, not the spelling.

Prior art check

I searched issues and pull requests, open and closed, in both iOfficeAI/AionCore and iOfficeAI/AionUi, for conversation create / clear / reset / delete / compact and for agent-facing CLI framings. I found no existing issue or PR asking for this. The closest items are not the same request:

• #772 / #770 — fork, HTTP only, forks from a chosen message rather than opening a fresh conversation.
• #795 / #798 — trusted provisioning protocols, explicitly conversation-independent.

If I missed an existing issue, happy to close this as a duplicate.

[mrjjstudio]

Follow-up from the same setup, and one correction to what I first believed I was seeing.

Deferred delivery does not survive the turn. The orchestrator tried to defer its own delivery instead: a detached background process that called session send-message 17 minutes later. It failed with

SESSION_CLI_HTTP_STATUS_ERROR command=session send-message status=401 Unauthorized
{"code":"runtime_auth_failed"}

The runtime token appears to be scoped to a live turn, so an orchestrator cannot hand its own delivery to a later moment either. Reporting this as an observation — I have not read the token lifetime code, and short-lived runtime credentials are a reasonable design, not a defect on their face.

Scheduling into another conversation — inconclusive, not blocked. The orchestrator also tried config cron jobs create targeting another conversation, and got HTTP 400 on four payload shapes (schedule as a string; schedule as {kind, expr, tz, description}; the full target/metadata shape mirroring an existing job record; and a minimal form).

That 400 does not show a scoping restriction. It matches iOfficeAI/AionUi#4042, where POST /api/cron/jobs rejects any JSON body including {}, failing at deserialization before field validation — which is also why every payload shape failed identically. #858 is open and unmerged against it.

Worth noting for whoever picks this up: the config CLI descriptor already treats a literal target as meaningful. cron jobs create declares conversation_id as a selector, and the contract defines a selector's literal form as "treat as conversation id" (config_capabilities.rs). So cross-conversation scheduling may already be intended and merely unreachable through the broken POST. That needs someone who can run it after #858 lands; I could not distinguish the two causes from outside.

Why this belongs on this issue. create and clear are two faces of one gap. This is a third: an orchestrator can dispatch work but cannot manage the lifecycle or the timing of the conversations it drives. If cross-conversation cron jobs create turns out to work once #858 merges, the timing half is already covered and only create/clear remain. If it does not, a session send-message deferral (--at <time> or similar) would close it.

The current-conversation family is documented as self-only by design — the bundled cron skill states each conversation has at most one scheduled task and routes through config cron current ... — so cron jobs is the only candidate surface for the cross-conversation case.