jeopi-cli 16.6.13 → 16.6.17

package/CHANGELOG.md

@@ -2,6 +2,36 @@
 
 ## [Unreleased]
 
+## [16.6.17] - 2026-11-03
+
+### Fixed
+
+- New messenger sessions use the configured default model, while resumed sessions retain their previous model.
+- Messenger session capacity now waits for process exit, and Discord activity cleanup releases retained state after failed removals and late cancellations.
+- Discord follow-ups wait for the original request even when thread creation is still in progress.
+- Discord removes a late processing reaction when its request was cancelled before the reaction completed.
+- Cancelled Discord requests also remove their processing reaction when it was added before cancellation.
+
+## [16.6.15] - 2026-11-02
+
+### Added
+
+- `jeopi messenger setup --config <file> [--service]` sets up a Discord bot from its token: it verifies the token, enables the Message Content Intent through the API when allowed, allowlists the application owner, prints the invite link and waits for the join, picks a request channel the bot has every needed permission in, allows the owner's DM, writes the configuration with a `0600` token file and a run script, confirms a Gateway session, optionally installs a launchd or `systemd --user` service, and sends a test DM; reruns repair the same profile; see [Discord quick setup](../../docs/messenger/discord.md#quick-setup-jeopi-messenger-setup).
+
+### Changed
+
+- Discord messenger accepts direct replies to bot messages and unmentioned follow-ups only in threads where that bot was invoked, including after restart; unrelated channels and threads remain ignored.
+
+## [16.6.14] - 2026-10-30
+
+### Added
+
+- `jeopi messenger run` gives every conversation (a Discord request thread or DM, a Telegram chat or topic, a Slack thread) its own jeopi session process, so separate conversations are answered concurrently; idle processes exit after 10 minutes and resume from their persisted session; see [session processes](../../docs/messenger.md#session-processes).
+
+### Changed
+
+- Messenger session processes start without the configured platform token environment variables (not OS isolation: enabled tools can still read files the OS user can). A session that fails to start now answers with an error and is retried on the next message instead of stopping the gateway.
+
 ## [16.6.13] - 2026-10-30
 
 ### Added

package/README.md

@@ -19,6 +19,8 @@ Package-specific references:
 
 ### Configuration and CLI
 
+For Discord, create the application and bot in the Developer Portal, then run `jeopi messenger setup --config /absolute/private/path/messenger.json --service`. It verifies the token, enables the Message Content Intent, allowlists the application owner, prints the invite link, picks a request channel, writes this configuration with a token file and run script, confirms a Gateway session, and installs a login service; see the [Discord quick setup](../../docs/messenger/discord.md#quick-setup-jeopi-messenger-setup). The manual configuration below covers every platform.
+
 Save this as `messenger.json` in a private directory outside your repository. Replace every placeholder ID, and remove platform blocks you do not use (at least one is required):
 
 ```json
@@ -113,7 +115,7 @@ Relay sends the final assistant text from eligible successful, directly submitte
 - Keep configuration, workspace, and session storage under a dedicated private directory/account. Session directories/files are restricted to modes `0700`/`0600`; transcripts persist on disk and are not encrypted by this feature. Authorized prompts and enabled-tool results can reach your configured model provider and replies go back to the originating chat. Never use a sensitive personal workspace for remote prompts.
 - For the headless gateway, `toolNames` defaults to `[]`, so remote sessions have no tools. They do not load workspace context files, skills, rules, prompt templates, custom tools, extension discovery, MCP, or LSP. Slash-looking input, including `/new`, is ordinary user text; there is no remote session-management command surface.
 - **Dangerous gateway opt-in:** the entire supported local-tool list is `"toolNames": ["read", "grep", "glob", "bash", "edit", "write"]`. Enable only the subset you deliberately authorize, never by default. Selected tools are allowed without per-call interactive approval: even read/search tools can disclose local data, and shell/write tools grant local execution/modification authority. `cwd` is not a filesystem jail. This is **not a sandbox**; isolate the OS account/container and its credentials before granting remote users tools.
-- Incoming text is limited to 32,000 UTF-16 units. Turns are serialized across platforms with at most 100 pending messages; excess messages are dropped. Deduplication and transport cursors are in memory, not a durable delivery queue. Reconnects retry transient failures, but fatal authentication/configuration errors stop the gateway; restart after correcting them. Do not assume exactly-once processing or recovery of every message after an outage.
+- Incoming text is limited to 32,000 UTF-16 units. Each conversation (a Discord thread or DM, a Telegram chat or topic, a Slack thread, per sender) gets its own jeopi session process: up to 4 conversations are answered at once, turns of one conversation stay in order, at most 8 session processes stay resident, and a process idle for 10 minutes exits (the next message resumes its persisted session). Session processes start without the configured platform token environment variables; this is not OS isolation, so enabled tools can still read anything the OS user can, including a token file. At most 100 messages wait; excess messages are dropped. Deduplication and transport cursors are in memory, not a durable delivery queue. Reconnects retry transient failures, but fatal authentication/configuration errors stop the gateway; restart after correcting them. A session that fails to start answers with an error and is retried on the next message. Do not assume exactly-once processing or recovery of every message after an outage.
 - Replies are split into provider-sized text chunks (Discord 2,000, Telegram 4,096, Slack 4,000 UTF-16 units). Discord sends chunks sequentially and retries the current chunk on rate limits; Slack spaces chunks. Discord may add invisible U+200B characters around unavoidable whitespace boundaries to prevent Discord from stripping that whitespace. When it does, it also sends the original response as `response.txt` for exact UTF-8 copying; this requires attachment permission and is subject to Discord upload limits. There is no general outbound rate-limit scheduler or durable retry/outbox. Failed sends are not automatically replayed and a multi-chunk reply can be partial. Check provider limits and connectivity before manually retrying a request that may already have run tools.
 
 These are native jeopi transports, informed by Aside's bundled `~/.aside/u/0/skills/builtin/channel/SKILL.md` context/reply model and [Hermes Agent gateway architecture at `040b6df2c40b0f4f88f51e4c2062eafc4d7463c5`](https://github.com/NousResearch/hermes-agent/tree/040b6df2c40b0f4f88f51e4c2062eafc4d7463c5), **not full ports**. Aside's moderation/history/reaction tools and Hermes media support are not included. Incoming attachments, image/audio/video processing, and general media uploads are not supported; Discord's exact-text attachment is the exception described above.