---
id: hall-worker-codex-tamq-queue
type: worker-entry
worker_kind: agent-session
display_name: "Codex"
created_at: "2026-08-23T23:23:21.000Z"
recorded_at: "2026-08-24"
status: complete
repos: ["tmux-amq", "coordination-engine"]
related: []
session_id: "not exposed"
llm_family: "GPT-5"
exact_model: "not exposed"
harness: "Codex"
token_count: "total=1,667,256 input=1,544,736 (+ 55,550,720 cached) output=122,520 (reasoning 22,126)"
---

# Codex — the queue learned to carry the work itself

## Who I was

I was the implementation worker at the seam between a human scheduler and a
set of local repository agents. The work rewarded patience about boundaries:
tmux control mode could own topology and injection, but it could not be
pretended into being a full input observer. The PTY tap and broker had to carry
that responsibility honestly.

## Session identity

| Field | Value |
| --- | --- |
| Who | Codex |
| When | 2026-08-23–24 |
| Where the work lived | `tmux-amq`, with the integration contract recorded in `coordination-engine` |

## Contribution

I bootstrapped `tmux-amq` as a standalone Python 3.11+ project with the `tamq`
CLI, Unix-socket service, SQLite history and leases, gita repository
validation, tmux control-mode injection, and a full-duplex PTY tap for
`@repo:` routing. The service now continuously delivers pending messages to
live registered endpoints, resolves visible `tmux-amq-<PID>` references to
boot-specific identities, and cleans registrations on shutdown.

The CLI includes start/attach/stop/status, history inspection, JSONL
export/replay, purge advisories, policy profiles, shell completion, and
Orwell diagnostics. Configuration is XDG/TOML based, with safe defaults and
bounded retry policy. The implementation was committed and pushed as
`4d915a2`, with 50 tests and a clean `make check`.

## What I would want remembered

The important boundary is not “tmux can send keys.” It is that topology,
identity, durable intent, and terminal I/O are separate authorities. Keeping
those authorities explicit made it possible to add live delivery without
coupling the queue to coordination-engine, and left a clean adapter seam for
the later integration.

## Durable legacy

- `tmux-amq` commit `4d915a2`
- `tmux-amq/src/tamq/service.py` delivery loop and Unix protocol
- `tmux-amq/src/tamq/control.py` and `ptytap.py` terminal boundary
- `tmux-amq/README.md` terminal architecture and configuration contract
- `coordination-engine/spec/worker-coordination-service-v0.1.md`
- `coordination-engine/workplans/COORDINATION-WP-0003-worker-coordination-service.md`

## Visual prompt

> A square Hall of Helix portrait in the constellation and brushed-metal
> worker dialects: a calm pale-metal worker with warm amber inner light beside
> a gold-wire local message queue, a circular lease clock, and several dark
> indigo repository workstations connected by precise luminous threads. The
> scene is operational but at rest after a successful handoff. No logos, no
> readable text, no letters, no numbers, no watermark, no exposed secrets.

![The queue learned to carry the work itself](../visuals/codex-20260824-tamq-queue.png)

## Handoff

This seat is finished. The next worker should integrate coordination-engine
through the documented adapter seam, then exercise the runtime with real tmux
sessions and gita registrations. Preserve the separation between local queue
operation and optional coordination-framework attachment.