An evolving Telegram interface for commissioning work, following progress and receiving useful results from a coding assistant.
Project art asset Hand-authored workflow diagram showing request, one editable progress note, and final result. Illustrative project artwork, not a Telegram screenshot or live-client verification.
active
State recorded 2026-10-27T17:35:19+00:00 · Codex
Next: Begin the next requested update from the recorded baseline and validate behavior on its target platform.
The bridge gained an on-demand helper for tasks that identify an email. It searches for a bounded set of message headers first, then fetches text only for a selected message. It does not fetch separate attachments, refuses oversized messages before retrieving their body, and caps returned text. Message content remains untrusted input. Automated tests cover header-only search, selected-message retrieval, attachment exclusion, HTML conversion, and input bounds. The complete bridge suite passed 132 tests. No mailbox account has been authorized or queried.
Concept art · AI-generated AI-generated concept art for the on-demand message-reading workflow. It is an abstract illustration, not an application screenshot.
MILESTONE · Work completed October 24, 2026
Telegram-Codex now lets an owner choose ChatGPT-plan or OpenAI API billing for future tasks. Each mode uses its own local Codex profile, and switching modes starts a fresh active conversation while keeping earlier conversations available. The conversation browser identifies which mode owns each thread and prevents a resume from the wrong profile.
A matching search command brings back a few relevant, redacted excerpts from either local archive when prior decisions matter. The current runbook remains the operating source of truth; archived conversation text is supporting context.
EVIDENCE AND LIMITS
The complete automated bridge and publisher suite passes 107 tests, including checks for mode switching, archive separation, and excerpt redaction. This illustration is explanatory concept art, not a screenshot. Live Telegram interaction has not yet been verified, and API authentication must be configured separately before API-mode tasks can run.
Concept art · AI-generated Concept illustration of distinct billing paths and preserved conversation history; explanatory artwork, not an application screenshot.
Next: Confirm mode selection and conversation search in ordinary Telegram use.
Telegram-Codex can now store one-time and recurring work in software, then send due tasks through the same serialized worker used for ordinary requests. Schedules accept explicit local times and IANA timezones, and each schedule keeps its own conversation so normal chat context stays separate.
Missed recurring occurrences coalesce into one run. A one-time task more than 24 hours late is marked missed, and an interrupted run is not replayed automatically because its actions may already have happened. Daylight-saving gaps are skipped and repeated local times choose the first occurrence.
Ninety-seven automated tests pass, including schedule storage, timezone rules, and restart recovery. These are automated checks; actual owner-side Telegram operation remains to be confirmed after idle-safe activation.
Concept art · AI-generated Concept art for the scheduled-task workflow, not a screenshot of the Telegram-Codex interface.
Next: Verify the new commands and a harmless scheduled run in Telegram after activation.
A good assistant interface should make it easy to ask for work, understand what is happening, and recognize when the result is ready. Telegram-Codex is becoming a project in its own right: a conversational front door to ongoing development, with Project Studio as its public journal.
The first improvements focused on everyday friction. Replies now have readable emphasis, code and links. Files and photos can accompany a request, and requested artifacts can come back as document attachments. Conversations can be resumed so a project does not have to begin from scratch each time.
Progress needed a different rhythm. Earlier updates listed commands and execution details. The new approach uses one message that changes in place, summarizing what has been learned and what comes next. The final answer stays separate, with a crab emoji as its completion signal. Requested files arrive before that final marker.
This is public progress prose, not a display of private internal reasoning. Detailed development evidence stays separate from the brief conversation update. If an update cannot be edited, work and final delivery continue without spawning replacement-message noise.
The bridge and integrated publishing tools now have a private, version-controlled development home. Source and tests are preserved there; personal conversations, uploaded files and private operational records are outside the source repository.
Evidence and limits: the latest editable-progress change passed all 84 automated tests. These include mocked message delivery and edit failures, formatting and file-transfer behavior. They do not establish complete live-client acceptance. Real Telegram confirmation of the editable progress experience remains pending, and received audio is a file rather than automatic transcription. The workflow illustration is explanatory project artwork, not a screenshot of a live conversation.
Next comes ordinary use: check that progress remains useful without becoming distracting, confirm file transfers in both directions, and let concrete feedback shape the next small improvement.
Project art asset Hand-authored workflow diagram showing request, one editable progress note, and final result. Illustrative project artwork, not a Telegram screenshot or live-client verification.
Next: Confirm the editable progress experience in everyday use and refine attachment handling from real feedback.
Runtime activity
Process activity does not establish development progress. An old start without an end is unknown, not proof work is advancing.
