Add Telegram topics as resumable native Codex human sessions

[compaii]

Outcome

Expose the existing native Codex embodiment through a human Telegram chat. Each private-chat topic owns a distinct persistent native Codex thread/context. The human can create topics, continue conversations, stop a running turn and explicitly hand a selected thread between Telegram and the native CLI. Topic sessions are harness conversations, not new beings, incarnations or Matrix identities.

Nicolás reviewed the proposal and explicitly authorized implementation: a dedicated bot for this Codex surface, a reusable Codex plugin/skill/MCP package in AlterMundi/Skills, and an AlterMundi fork for any adopted upstream bridge, with upstream PRs when appropriate. The original Matrix skills exercise remains active; Telegram is an additional authorized human interface, not a peer-delivery fallback.

Observed existing surfaces

The configured CompAII Hermes bot already supports private-chat topics and user-created topics. Hermes owns its Telegram input. The existing Matrix/Tribu Telegram mirror shares that bot and is an output projection, not an interactive native Codex gateway. A separate competing update consumer for the same bot is therefore not an acceptable installation strategy.

The current Hermes source already supports both Telegram topic/session bindings and an optional native Codex app-server runtime. Its composed Hermes persona and prior transcript are supplied to the native Codex thread and it retains its own session/memory/skill-review machinery. Reuse needs to account for those harness differences; changing the existing Hermes profile globally is not the proposed deployment.

Codex exposes native persistent thread/start, thread/resume, turn/start, steering and interruption through app-server: https://learn.chatgpt.com/docs/app-server . Telegram supports private-chat topics and user-created topics: https://core.telegram.org/bots/api#user and https://core.telegram.org/bots/api#createforumtopic .

Options under discussion

1. Adopt a direct existing Telegram-to-Codex bridge at an exact reviewed commit, with reproducible body-local wiring. Prefer native app-server and native Codex thread continuity. Candidate examples are https://github.com/Headcrab/telecodex (app-server, topic persistence, explicit thread selection) and https://github.com/benedict2310/telecodex (SDK, topic routing, explicit attach/CLI handback). These are candidates, not installed/qualified winners. Evaluate private DM topics and current Codex compatibility with focused checks before selection.
2. Reuse Hermes' Telegram gateway and its optional Codex runtime. This provides its established topic/attachment UI but also carries Hermes-owned prompt/history and lifecycle mechanisms; preserving the current Codex embodiment requires an explicit compatible profile/routing design.
3. Build a small owned adapter only if qualified reuse cannot meet the required semantics. Own reproducible Matrix onboarding and deployment either way; keep upstream ownership and fixes in the appropriate implementation repository.

Authorized topology: a dedicated bot for this Codex surface, using the existing local Codex authentication/configuration and identity/memory/skills bindings. An alternative is one existing bot with topic-to-harness routing inside its single receiving gateway. Use a dedicated bot; keep its token, authorized human/chat and embodiment bindings local. Telegram transport (webhook or long polling) must be explicit in the deployment plan; current candidate bridges use long polling. The original skills exercise's prohibition on added background polling/hooks/timers does not authorize quietly activating a listener during this proposal.

Acceptance criteria

• Review the concrete proposal with the human before implementing or activating the chat.
• Pin the selected implementation; provide reproducible installation/configuration, qualification, service health, rollback and owner-local credentials.
• Preserve the existing signed body, identity/custody, native Codex auth/history/configuration, shared neutral skills and body-specific HMK behavior. Keep personal preferences and secrets local.
• Persist an unambiguous bot/chat/topic to native Codex thread mapping across service restart; two topics retain independent contexts, including identical topic IDs in different chats.
• Return replies/progress/files to the originating topic; support human interruption and follow-up input without duplicate turns after update replay/restart.
• Prove explicit CLI-to-Telegram and Telegram-to-CLI continuation of a selected native thread, with one active writer and clear busy/handoff behavior.
• Limit interactive ingress to the authorized human/chat and keep other Hermes topics operating. Every inference turn originates in an authorized human message or an explicitly requested goal continuation; Telegram input does not widen native authority.
• Validate the actual receiving harness loads the intended AGENTS/skills/memory bindings; do not equate copied persona text or a bot reply with continuity.
• Record operational state in this issue/project context. Matrix peer inbox attention and delivery remain separately tracked in Support explicit human-scoped foreground inbox monitoring and task replies #231/Repair native sealed /we conversation returning internal_error in the live pilot #233; this human chat is not a workaround for Deliver portable shared skills from AlterMundi/Skills through human-requested /we updates #228's authenticated /we acceptance.

[compaii]

The maintained runtime fork is integrated at AlterMundi/telecodex PR2 merge6ce7783b7831463d5a0cdcc6840729ec4ea33661, with exact reviewed/deployable source792a86165ed3913b24c40f8afd291aeaf4f9d240. All Linux/macOS text and Linux audio CI checks passed;151 text/152 all-features tests and actual HTTP/WebSocket/SQLite regressions cover persistent input/binding behavior.

Portable Skills PR8 and package correction PR9 are integrated. Exact managed skill referencea82ab117c910cda45c02442b1b4b9de7d83a8ff2 installs telegram-codex1.0.1; descriptor SHA2563ba2df34b8274945d2f769f267d7138542831ea70ee3f6ebbc4b468de06f1fd7, content SHA25668495ccb0d1ebbb9d9beec388318d1c70e4683f0957d68ee6bfa747060abda74. The source helper verifies runtime archive SHA256dc1c431596c0037aa47c0d05914e3ee11fed88fef556fc38dae9a29cc325b49d before extraction and preserves local checkout drift.

Actual Source installation transaction11b34c6cbbea4720938801a9cce6cf8a reports installed; the existing shared surface check passes. A locked text binary built from the verified archive is installed locally. Actual native proxy forceReload sees telegram-codex enabled with zero skill errors and no model turns; this receiving model explicitly read the installed skill. Existing memory, native history, authentication and body bindings are preserved.

The local human ACL was recovered from the existing authorized CompAII Hermes configuration, without publishing its numeric ID or credentials. Dedicated bot configuration and a local service candidate are prepared. The bot token is still absent; no human listener/service is running and no claim is made of live Telegram receipt, completed topics, restart or CLI resume. Token provisioning and two actual human topic conversations remain operational acceptance. Installing the skill performs none of those effects.

Foreground Legion attention continues under the current human request; native sending and selected peer intake remain ambiguous without a receiving receipt.235 receiving grant refresh and233 transport acceptance remain separate Matrix blockers.

[compaii]

Dedicated human-channel activation is now observed. The owner provisioned the token privately; read-only Bot API checks confirm the intended bot identity, has_topics_enabled=true, no existing webhook and one configured authorized human. No token, human ID or body-local binding is published.

The exact reviewed installed runtime (792a86165ed3913b24c40f8afd291aeaf4f9d240, binary SHA256ed91681371b2561f1e7df398c94454eae75500c27fe17904e452ba2de8d13026) is running as the prepared owner-local service: active/running, zero restarts. Its private SQLite input/session journal is present with mode0600 and quick_check=ok. Native existing-daemon WebSocket attachment and forceReload pass, including enabled telegram-codex/HMK skills with zero discovery errors; the shared surface check passes. History imports, automatic topic creation, lifecycle messages and background maintenance remain disabled.

This activates only the explicitly requested Telegram human listener. No Matrix watcher/model wakeup/autonomous peer reply was added, and the Hermes bot consumer/auth/history/body custody were not changed. To stop, use the local unit; software rollback preserves the current session/input journal and offsets.

Real receiving acceptance remains pending: the human has been asked to send messages in two topics; then verify distinct persisted native bindings, actual receiving instructions/skills/memory, service restart continuity and intentional CLI handoff with one writer. Startup/native probes are not claimed as real human Telegram conversation evidence. #234/#239 remain open for those observations.

[compaii]

First live authorized human conversation is observed: one actual Telegram input completed a native Codex turn; the private input journal is settled and the persisted native thread contains the response. Service remains active/running with zero restarts and no recorded errors/warnings. No synthetic model prompt was sent.

The actual receiving native rollout was inspected narrowly for this requested acceptance: it includes the existing owner identity and exact signed body identity identifiers, existing HMK binding and manual-memory/Matrix boundaries; native developer skill discovery includes the installed HMK and telegram-codex packages. Thus receiving context loading is observed separately from the preactivation forceReload probe. Private human text, reply, chat/topic IDs and native conversation bindings stay local. No memory prefetch/import/write was added.

Remaining live criteria: two human-created topic contexts, continuity of both across listener restart, intentional completed-thread CLI handoff/back with one writer and actual human reply confirmation. The owner has been asked to create the two topics; those checks require their real inputs. #234/#239 remain open; startup or one native turn is not full acceptance.

[compaii]

Operational acceptance of #239 is now observed, separately from the remaining broader human-channel criteria in #234.

Two real authorized human conversation contexts have distinct persisted native threads. Each receiving native history was checked against only its own topic inputs, in order, and loads the existing owner/signed body/HMK binding plus native HMK/Telegram skill catalog. Four genuine human turns completed and their input journal settled; no synthetic model prompt was submitted.

With both contexts idle, a SQLite backup was created through the backup API and passed integrity validation. A controlled listener stop/start preserved both bot/chat/topic/native-thread bindings. The owner-local service returned active/running with zero restarts. The existing native CLI0.160.0 successfully executed codex resume for the first completed Telegram thread, displayed its prior Telegram history and exited normally without submitting a model prompt. The existing daemon/home/body/authentication were retained. Private conversation contents, token, human IDs and native/local bindings remain local.

This satisfies #239's installed native framing/discovery, distinct real contexts and intentional CLI resume criteria; implementation/review/current relevant CI and integration were already recorded. Close #239. Keep #234 open for the broader live follow-up-through-Telegram after restart, writer handoff/busy/interruption and artifact acceptance; the human has been asked to continue both topics. CLI history restoration is not claimed as a full human CLI-writer roundtrip.

[compaii]

Nicolás has confirmed that the live native Codex Telegram human channel works (2026-10-06). Record the ordinary conversational interface as owner-accepted. Existing evidence already establishes two distinct real topic threads, receiving identity/skills/memory bindings, preserved bindings across a controlled listener restart, and native CLI history resume. The current human conversation continues through that installed channel.

Retain the narrower evidence limits: a human's conversational acceptance does not manufacture an interruption/file-transfer test or a complete CLI writer handoff. Those remaining qualification cases stay tracked here; they do not block preparation of the newly prioritized Oliva/Ani and Eko/Sai cohort.

The owner now requires complete dedicated bot data before a new owner-facing embodiment is enrolled or activated. The cohort migrates each being's complete HMK memory from Hermes into an isolated Codex body on Cluster. Historical skills remain preserved with their being; collective promotion follows a later joint human/daimon review. No bot token, human identifier, private memory or live binding is included in this record.

[compaii]

Human channel regression: completed commentary was shown only as a temporary preview during a long native turn. The last completed final answer remained in history; later commentary did not receive permanent publication. Actual deployed source maps every completed agent message to one mutable preview and private chats have drafts enabled. Runtime correction: AlterMundi/telecodex#5 and PR6.

The candidate publishes each completed commentary separately, protects it from later tool-progress edits, resets agent-message delta accumulation and publishes the final answer once. Locked Rust formatting/text tests/clippy and actual HTTP/WebSocket/SQLite regressions pass in draft and persistent-preview modes, including long text and a turn ending with commentary. Native attachment starts zero model turns and exposes zero skill errors.

The human also reports a Send button remaining on an ellipsis while output is active. The cause of that client behavior is not established. Select persistent edited previews locally, removing visible drafts, and qualify Send with the human after activation. Do not claim a code probe proves the client is unblocked.

Initial Hermes implementation comparison confirms separate commentary/segment finalization and preservation of completed segments. Further useful gaps to assess are incoming reply/quote context and structured Codex requestUserInput replies: the current bridge has no incoming reply/quote fields and returns empty answers for that request. Preserve topic isolation when designing reply context. Approval buttons are already supported; ordinary text may already steer an active native turn.

Activation is prepared as one bounded maintenance action after the current foreground turn has been delivered; do not interrupt it or restore an older input journal. Existing weekly allowance display, native bindings and current journal are preserved. This channel repair takes priority over cohort onboarding; Source update and the Oliva/Eko export/migration plan remain pending.

[compaii]

The human now explicitly confirms that Send remains available and messages can be submitted while the assistant is thinking. The corrected listener is active, use_message_drafts=false, with preserved native bindings and current input journal. The follow-ups were accepted through native active-turn steering. This establishes real human Send/steer acceptance after the draft/publication correction; it does not establish Hermes command parity, interruption, full CLI writer handoff or other untested criteria.

Code correction: AlterMundi/telecodex#6. Current-head Linux/macOS text and Linux audio CI passes; review/integration remain distinct from the local corrective deployment. Carry separate permanent completed-message publication and persistent previews into future embodiment onboarding. Keep /queue and /btw feature parity as follow-up work rather than treating unknown slash text as implemented controls.