tmux-agent 0.1.0

package/.specify/templates/spec-template.md

@@ -0,0 +1,135 @@
+# Feature Specification: [FEATURE NAME]
+
+**Feature Branch**: `[###-feature-name]`  
+**Created**: [DATE]  
+**Status**: Draft  
+**Input**: User description: "$ARGUMENTS"
+
+## User Scenarios & Testing _(mandatory)_
+
+<!--
+  IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
+  Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
+  you should still have a viable MVP (Minimum Viable Product) that delivers value.
+
+  Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
+  Think of each story as a standalone slice of functionality that can be:
+  - Developed independently
+  - Tested independently
+  - Deployed independently
+  - Demonstrated to users independently
+-->
+
+### User Story 1 - [Brief Title] (Priority: P1)
+
+[Describe this user journey in plain language]
+
+**Why this priority**: [Explain the value and why it has this priority level]
+
+**Independent Test**: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+2. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+### User Story 2 - [Brief Title] (Priority: P2)
+
+[Describe this user journey in plain language]
+
+**Why this priority**: [Explain the value and why it has this priority level]
+
+**Independent Test**: [Describe how this can be tested independently]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+### User Story 3 - [Brief Title] (Priority: P3)
+
+[Describe this user journey in plain language]
+
+**Why this priority**: [Explain the value and why it has this priority level]
+
+**Independent Test**: [Describe how this can be tested independently]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+[Add more user stories as needed, each with an assigned priority]
+
+### Edge Cases
+
+<!--
+  ACTION REQUIRED: The content in this section represents placeholders.
+  Fill them out with the right edge cases.
+-->
+
+- What happens when [boundary condition]?
+- How does system handle [error scenario]?
+
+## Requirements _(mandatory)_
+
+<!--
+  ACTION REQUIRED: The content in this section represents placeholders.
+  Fill them out with the right functional requirements.
+-->
+
+### Functional Requirements
+
+- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
+- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]
+- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
+- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
+- **FR-005**: System MUST [behavior, e.g., "log all security events"]
+
+_Example of marking unclear requirements:_
+
+- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
+- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
+
+### Non-Functional Requirements (Quality)
+
+<!--
+  If this feature is performance/scale sensitive:
+  - Define budgets (latency/throughput/memory/alloc) and how they are measured
+  - Define observability: logs/metrics/traces + failure triage signals
+-->
+
+- **NFR-001**: If performance-sensitive, system MUST define budgets for critical paths
+  and record a measurable baseline before implementation.
+- **NFR-002**: System MUST provide structured diagnostic signals (logs/metrics/traces)
+  for key flows, with a documented enable/disable cost model.
+- **NFR-003**: Identifiers used in diagnostics SHOULD be stable and searchable.
+- **NFR-004**: Error handling MUST be explicit for user-facing failures, and MUST include
+  a clear triage path (where to look, what to collect).
+- **NFR-005**: If this feature introduces breaking changes, the project MUST document
+  the change and migration steps (where applicable).
+
+### Key Entities _(include if feature involves data)_
+
+- **[Entity 1]**: [What it represents, key attributes without implementation]
+- **[Entity 2]**: [What it represents, relationships to other entities]
+
+## Success Criteria _(mandatory)_
+
+<!--
+  ACTION REQUIRED: Define measurable success criteria.
+  These must be technology-agnostic and measurable.
+-->
+
+### Measurable Outcomes
+
+- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
+- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
+- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
+- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
+- **SC-005**: [Performance metric, e.g., "No regression in p95 latency / allocations for [hot path]"]
+- **SC-006**: [Diagnosability metric, e.g., "Devtools can explain 'why' for [event] with causal chain"]

package/.specify/templates/tasks-template.md

@@ -0,0 +1,269 @@
+---
+
+description: "Task list template for feature implementation"
+---
+
+# Tasks: [FEATURE NAME]
+
+**Input**: Design documents from `/specs/[###-feature-name]/`
+**Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/, notes/ (optional)
+
+**Tests**: The examples below include test tasks. Tests are OPTIONAL by default - only include
+them if explicitly requested in the feature specification, or if your project’s quality gates require
+tests for this change. If a change touches performance-sensitive paths, include performance regression
+defenses (baseline + guard) unless explicitly justified. If a change introduces breaking changes, include
+a migration note task (plan.md / PR) and follow the project’s compatibility policy (do not add “silent”
+compat layers unless they are explicitly planned).
+
+**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.
+
+## Format: `[ID] [P?] [Story] Description`
+
+- **[P]**: Can run in parallel (different files, no dependencies)
+- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
+- Include exact file paths in descriptions
+
+## Path Conventions
+
+- **Single project**: `src/`, `tests/` at repository root
+- **Web app**: `backend/src/`, `frontend/src/`
+- **Mobile**: `api/src/`, `ios/src/` or `android/src/`
+- Paths shown below assume single project - adjust based on plan.md structure
+
+<!--
+  ============================================================================
+  IMPORTANT: The tasks below are SAMPLE TASKS for illustration purposes only.
+
+  The $speckit tasks stage MUST replace these with actual tasks based on:
+  - User stories from spec.md (with their priorities P1, P2, P3...)
+  - Feature requirements from plan.md
+  - Entities from data-model.md
+  - Endpoints from contracts/
+
+  Tasks MUST be organized by user story so each story can be:
+  - Implemented independently
+  - Tested independently
+  - Delivered as an MVP increment
+
+  DO NOT keep these sample tasks in the generated tasks.md file.
+  ============================================================================
+-->
+
+## Phase 1: Setup (Shared Infrastructure)
+
+**Purpose**: Project initialization and basic structure
+
+- [ ] T001 Create project structure per implementation plan
+- [ ] T002 Initialize [language] project with [framework] dependencies
+- [ ] T003 [P] Configure linting and formatting tools
+
+---
+
+## Phase 2: Foundational (Blocking Prerequisites)
+
+**Purpose**: Core infrastructure that MUST be complete before ANY user story can be implemented
+
+**⚠️ CRITICAL**: No user story work can begin until this phase is complete
+
+Examples of foundational tasks (adjust based on your project):
+
+- [ ] T004 Setup database schema and migrations framework
+- [ ] T005 [P] Implement authentication/authorization framework
+- [ ] T006 [P] Setup API routing and middleware structure
+- [ ] T007 Create base models/entities that all stories depend on
+- [ ] T008 Configure error handling and logging infrastructure
+- [ ] T00X [P] Define unified minimal IR + drift prevention (docs/specs + parser/codegen)
+- [ ] T00X [P] Define deterministic identity model (instanceId/txnSeq/opId) and remove random/time defaults
+- [ ] T00X [P] Enforce transaction boundary (no IO in txn window, no writable ref escape hatches)
+- [ ] T00X [P] Define external reactive source integration: signal-dirty (pull-based), no render-level tearing (single snapshot anchor), and sharded notify to avoid O(N) selector work
+- [ ] T00X [P] Encapsulate internal hooks as explicit injectable contracts (Runtime Services); avoid magic fields / parameter explosion; document migration in specs/[###-feature]/plan.md
+- [ ] T00X [P] Normalize package public submodules: PascalCase `src/*.ts` (except `index.ts`/`global.d.ts`), move non-submodule code into `src/internal/**`, and keep `exports` from exposing internals
+- [ ] T00X [P] Decompose oversized modules/files (≥1000 LOC or expected to exceed): define a decomposition brief (mutually exclusive submodules), pick structure (flat `*.*.ts` vs directory), keep refactor semantics-preserving, and add incremental verification checkpoints
+- [ ] T00X [P] Add controlled trial-run harness (RunSession + Evidence/IR export) with schema validation; ensure parallel sessions are isolated
+- [ ] T00X [P] Define performance budget + baseline measurement approach (benchmark/profile)
+- [ ] T00X [P] Define diagnostic events/Devtools surfaces + expected overhead (enabled vs disabled)
+- [ ] T00X [P] Provide user-facing performance mental model (≤5 keywords, cost model, optimization ladder) and align terminology across docs/benchmarks/diagnostics
+- [ ] T009 Setup environment configuration management
+
+**Checkpoint**: Foundation ready - user story implementation can now begin in parallel
+
+---
+
+## Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP
+
+**Goal**: [Brief description of what this story delivers]
+
+**Independent Test**: [How to verify this story works on its own]
+
+### Tests for User Story 1 (OPTIONAL - only if tests requested) ⚠️
+
+> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
+
+- [ ] T010 [P] [US1] Contract test for [endpoint] in tests/contract/test\_[name].py
+- [ ] T011 [P] [US1] Integration test for [user journey] in tests/integration/test\_[name].py
+
+### Implementation for User Story 1
+
+- [ ] T012 [P] [US1] Create [Entity1] model in src/models/[entity1].py
+- [ ] T013 [P] [US1] Create [Entity2] model in src/models/[entity2].py
+- [ ] T014 [US1] Implement [Service] in src/services/[service].py (depends on T012, T013)
+- [ ] T015 [US1] Implement [endpoint/feature] in src/[location]/[file].py
+- [ ] T016 [US1] Add validation and error handling
+- [ ] T017 [US1] Add logging for user story 1 operations
+
+**Checkpoint**: At this point, User Story 1 should be fully functional and testable independently
+
+---
+
+## Phase 4: User Story 2 - [Title] (Priority: P2)
+
+**Goal**: [Brief description of what this story delivers]
+
+**Independent Test**: [How to verify this story works on its own]
+
+### Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️
+
+- [ ] T018 [P] [US2] Contract test for [endpoint] in tests/contract/test\_[name].py
+- [ ] T019 [P] [US2] Integration test for [user journey] in tests/integration/test\_[name].py
+
+### Implementation for User Story 2
+
+- [ ] T020 [P] [US2] Create [Entity] model in src/models/[entity].py
+- [ ] T021 [US2] Implement [Service] in src/services/[service].py
+- [ ] T022 [US2] Implement [endpoint/feature] in src/[location]/[file].py
+- [ ] T023 [US2] Integrate with User Story 1 components (if needed)
+
+**Checkpoint**: At this point, User Stories 1 AND 2 should both work independently
+
+---
+
+## Phase 5: User Story 3 - [Title] (Priority: P3)
+
+**Goal**: [Brief description of what this story delivers]
+
+**Independent Test**: [How to verify this story works on its own]
+
+### Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️
+
+- [ ] T024 [P] [US3] Contract test for [endpoint] in tests/contract/test\_[name].py
+- [ ] T025 [P] [US3] Integration test for [user journey] in tests/integration/test\_[name].py
+
+### Implementation for User Story 3
+
+- [ ] T026 [P] [US3] Create [Entity] model in src/models/[entity].py
+- [ ] T027 [US3] Implement [Service] in src/services/[service].py
+- [ ] T028 [US3] Implement [endpoint/feature] in src/[location]/[file].py
+
+**Checkpoint**: All user stories should now be independently functional
+
+---
+
+[Add more user story phases as needed, following the same pattern]
+
+---
+
+## Phase N: Polish & Cross-Cutting Concerns
+
+**Purpose**: Improvements that affect multiple user stories
+
+- [ ] TXXX [P] Documentation updates in docs/
+- [ ] TXXX Code cleanup and refactoring
+- [ ] TXXX Performance optimization across all stories
+- [ ] TXXX Performance regression guard (bench/profile baseline + CI-friendly check if applicable)
+- [ ] TXXX Diagnosability & explainability polish (events/trace/devtools UX + overhead validation)
+- [ ] TXXX [P] Additional unit tests (if requested) in tests/unit/
+- [ ] TXXX Security hardening
+- [ ] TXXX Run quickstart.md validation
+
+---
+
+## Dependencies & Execution Order
+
+### Phase Dependencies
+
+- **Setup (Phase 1)**: No dependencies - can start immediately
+- **Foundational (Phase 2)**: Depends on Setup completion - BLOCKS all user stories
+- **User Stories (Phase 3+)**: All depend on Foundational phase completion
+  - User stories can then proceed in parallel (if staffed)
+  - Or sequentially in priority order (P1 → P2 → P3)
+- **Polish (Final Phase)**: Depends on all desired user stories being complete
+
+### User Story Dependencies
+
+- **User Story 1 (P1)**: Can start after Foundational (Phase 2) - No dependencies on other stories
+- **User Story 2 (P2)**: Can start after Foundational (Phase 2) - May integrate with US1 but should be independently testable
+- **User Story 3 (P3)**: Can start after Foundational (Phase 2) - May integrate with US1/US2 but should be independently testable
+
+### Within Each User Story
+
+- Tests (if included) MUST be written and FAIL before implementation
+- Models before services
+- Services before endpoints
+- Core implementation before integration
+- Story complete before moving to next priority
+
+### Parallel Opportunities
+
+- All Setup tasks marked [P] can run in parallel
+- All Foundational tasks marked [P] can run in parallel (within Phase 2)
+- Once Foundational phase completes, all user stories can start in parallel (if team capacity allows)
+- All tests for a user story marked [P] can run in parallel
+- Models within a story marked [P] can run in parallel
+- Different user stories can be worked on in parallel by different team members
+
+---
+
+## Parallel Example: User Story 1
+
+```bash
+# Launch all tests for User Story 1 together (if tests requested):
+Task: "Contract test for [endpoint] in tests/contract/test_[name].py"
+Task: "Integration test for [user journey] in tests/integration/test_[name].py"
+
+# Launch all models for User Story 1 together:
+Task: "Create [Entity1] model in src/models/[entity1].py"
+Task: "Create [Entity2] model in src/models/[entity2].py"
+```
+
+---
+
+## Implementation Strategy
+
+### MVP First (User Story 1 Only)
+
+1. Complete Phase 1: Setup
+2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
+3. Complete Phase 3: User Story 1
+4. **STOP and VALIDATE**: Test User Story 1 independently
+5. Deploy/demo if ready
+
+### Incremental Delivery
+
+1. Complete Setup + Foundational → Foundation ready
+2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
+3. Add User Story 2 → Test independently → Deploy/Demo
+4. Add User Story 3 → Test independently → Deploy/Demo
+5. Each story adds value without breaking previous stories
+
+### Parallel Team Strategy
+
+With multiple developers:
+
+1. Team completes Setup + Foundational together
+2. Once Foundational is done:
+   - Developer A: User Story 1
+   - Developer B: User Story 2
+   - Developer C: User Story 3
+3. Stories complete and integrate independently
+
+---
+
+## Notes
+
+- [P] tasks = different files, no dependencies
+- [Story] label maps task to specific user story for traceability
+- Each user story should be independently completable and testable
+- Verify tests fail before implementing
+- Commit after each task or logical group
+- Stop at any checkpoint to validate story independently
+- Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence

package/README.md

@@ -0,0 +1,128 @@
+# agent-tmux
+
+LLM-friendly tmux control plane CLI for windows/panes — with Codex TUI helpers.
+
+<p align="center">
+  <a href="./README.md">English</a> · <a href="./README.zh-CN.md">中文</a>
+</p>
+
+`agent-tmux` is a small CLI that lets an AI agent (or you) control [tmux][tmux] safely:
+list/snapshot windows and panes, resolve targets, send text/keys, read output, and (optionally)
+drive a [Codex CLI][codex-cli] TUI pane with reliability guardrails.
+
+### Why
+
+- Designed for agent loops: minimal stdout by default; single-line JSON with `--json`.
+- Safe targeting: resolves to stable `%pane_id` / `@<window_id>%<pane_id>`; ambiguity fails with candidates.
+- Codex helpers: `codex send/session-info/fork-home/spawn` for multi-pane workflows.
+
+### Requirements
+
+- [Bun][bun] 1.2+ (for installing dependencies)
+- [Node.js][nodejs] 20+
+- [tmux][tmux] 3.x
+- For `ui select`: tmux with `display-popup` and [fzf][fzf]
+
+### Install (local dev)
+
+```bash
+bun install
+bun run build
+bun dist/cli/index.js --help
+```
+
+Optional global binary:
+
+```bash
+bun link
+agent-tmux --help
+```
+
+### Quick start
+
+```bash
+agent-tmux window ls
+agent-tmux snapshot
+agent-tmux find codex
+agent-tmux send %717 "echo hello"
+agent-tmux read %717 --lines 20
+```
+
+### Codex (TUI) quick start
+
+```bash
+agent-tmux codex spawn
+agent-tmux codex send %717 "continue" --capture-tail 60
+agent-tmux codex session-info %717 --json
+```
+
+Notes:
+- `codex spawn` / `ui select` are meant to run inside tmux (so `TMUX_PANE` is available). Outside tmux, pass an explicit `--origin <paneTarget>` for `codex spawn`.
+
+### Command overview
+
+```bash
+agent-tmux window ls|new|rename|kill
+agent-tmux pane spawn|title|kill
+agent-tmux snapshot
+agent-tmux find <query>
+agent-tmux send <paneTarget> <text>
+agent-tmux read <paneTarget> [--lines N]
+agent-tmux codex send|session-info|fork-home|spawn
+agent-tmux ui select --spec -
+```
+
+### Targeting (paneTarget)
+
+- `%<pane_id>` (stable)
+- `@<window_id>%<pane_id>` (stable + asserts window)
+- `IDX` (number; within current window scope)
+- Keyword substring match against `COMMAND/TITLE` (within current window scope)
+
+### Output contract
+
+- Success: exit code `0`; stdout is the result only.
+- Failure: non-zero exit code; stderr starts with `Error:`.
+- `--json`: stdout is a single-line JSON object (no extra text).
+- stdin is read only when an argument is explicitly `-` or `--spec -`.
+
+### Environment variables
+
+- `AGENT_TMUX_SERVER` / `AGENT_TMUX_SOCKET`: pass `tmux -L <name>` to target a specific tmux server.
+
+### Usage with AI agents
+
+Add to your project instructions (e.g. `AGENTS.md`):
+
+```markdown
+## tmux control
+
+Use `agent-tmux` for tmux automation. Prefer `--json` for machine-readable output.
+
+Typical flow:
+1) `agent-tmux snapshot` / `agent-tmux find <query>`
+2) `agent-tmux send <paneTarget> <text>`
+3) `agent-tmux read <paneTarget> --lines 60`
+```
+
+### Tests
+
+```bash
+bun run test
+```
+
+Codex e2e tests (requires local codex + credentials):
+
+```bash
+AGENT_TMUX_E2E_CODEX=1 bun run test
+```
+
+---
+
+## Links
+
+[codex-cli]: https://github.com/openai/codex
+[bun]: https://bun.sh
+[fzf]: https://github.com/junegunn/fzf
+[nodejs]: https://nodejs.org/
+[tmux]: https://github.com/tmux/tmux

package/README.zh-CN.md

@@ -0,0 +1,127 @@
+# agent-tmux
+
+面向 AI agent 的 tmux 控制面 CLI（支持 Codex TUI 辅助命令）。
+
+<p align="center">
+  <a href="./README.md">English</a> · <a href="./README.zh-CN.md">中文</a>
+</p>
+
+`agent-tmux` 让 AI agent（或你）安全操控 [tmux][tmux]：列出/快照 window 与 pane、解析目标、发送文本/按键、读取输出；并提供一组面向 [Codex CLI][codex-cli] TUI 的增强命令，用于多 pane 并行与更可靠的输入提交。
+
+## 为什么要用它
+
+- 面向 agent 调用：默认 stdout 极简；`--json` 输出单行 JSON。
+- 安全定位：目标会先解析为稳定 `%pane_id` / `@<window_id>%<pane_id>`；歧义直接失败并给候选。
+- Codex 增强：`codex send/session-info/fork-home/spawn` 支持多会话、多 pane 工作流。
+
+## 运行环境
+
+- [Bun][bun] 1.2+（用于安装依赖）
+- [Node.js][nodejs] 20+
+- [tmux][tmux] 3.x
+- `ui select` 需要 tmux 支持 `display-popup` 且系统存在 [fzf][fzf]
+
+## 安装（本地开发）
+
+```bash
+bun install
+bun run build
+bun dist/cli/index.js --help
+```
+
+可选：全局安装到 `agent-tmux` 命令：
+
+```bash
+bun link
+agent-tmux --help
+```
+
+## 快速开始
+
+```bash
+agent-tmux window ls
+agent-tmux snapshot
+agent-tmux find codex
+agent-tmux send %717 "echo hello"
+agent-tmux read %717 --lines 20
+```
+
+## Codex（TUI）快速开始
+
+```bash
+agent-tmux codex spawn
+agent-tmux codex send %717 "继续" --capture-tail 60
+agent-tmux codex session-info %717 --json
+```
+
+注意：
+- `codex spawn` / `ui select` 预期在 tmux 内运行（需要 `TMUX_PANE`）。在 tmux 外运行 `codex spawn` 时，请显式提供 `--origin <paneTarget>`。
+
+## 命令概览
+
+```bash
+agent-tmux window ls|new|rename|kill
+agent-tmux pane spawn|title|kill
+agent-tmux snapshot
+agent-tmux find <query>
+agent-tmux send <paneTarget> <text>
+agent-tmux read <paneTarget> [--lines N]
+agent-tmux codex send|session-info|fork-home|spawn
+agent-tmux ui select --spec -
+```
+
+## 目标定位（paneTarget）
+
+- `%<pane_id>`（稳定定位）
+- `@<window_id>%<pane_id>`（稳定定位 + 断言所属 window）
+- `IDX`（纯数字；仅在当前 window scope 内）
+- 关键词（对 `COMMAND/TITLE` 的大小写不敏感子串匹配；仅在当前 window scope 内）
+
+## 输出契约（给 agent 用）
+
+- 成功：exit code `0`；stdout 只输出结果。
+- 失败：非零 exit code；stderr 以 `Error:` 开头。
+- `--json`：stdout 为单行 JSON（不夹杂其他文本）。
+- 默认不读 stdin；只有参数显式为 `-` 或 `--spec -` 才读到 EOF。
+
+## 环境变量
+
+- `AGENT_TMUX_SERVER` / `AGENT_TMUX_SOCKET`：传入 `tmux -L <name>`，用于指定 tmux server。
+
+## 给 AI agent 的用法建议
+
+建议把下面片段加入项目说明（例如 `AGENTS.md`）：
+
+```markdown
+## tmux 控制
+
+使用 `agent-tmux` 做 tmux 自动化。机器可读场景优先 `--json`。
+
+常见流程：
+1) `agent-tmux snapshot` / `agent-tmux find <query>`
+2) `agent-tmux send <paneTarget> <text>`
+3) `agent-tmux read <paneTarget> --lines 60`
+```
+
+## 测试
+
+```bash
+bun run test
+```
+
+Codex e2e（需要本机 codex + 凭据）：
+
+```bash
+AGENT_TMUX_E2E_CODEX=1 bun run test
+```
+
+---
+
+## Links
+
+[codex-cli]: https://github.com/openai/codex
+[bun]: https://bun.sh
+[fzf]: https://github.com/junegunn/fzf
+[nodejs]: https://nodejs.org/
+[tmux]: https://github.com/tmux/tmux
+