oh-my-customcodex 0.5.1 → 0.5.2

package/templates/.claude/rules/MUST-tool-identification.md

@@ -13,6 +13,25 @@ Every tool call MUST be prefixed with agent and model identification:
 
 For parallel calls: list ALL identifications BEFORE the tool calls.
 
+## Short Response Discipline
+
+Brief diagnostics and quick checks are not exempt. If a visible response will be followed by a tool call, include the tool prefix first even when the natural-language update is one sentence.
+
+Anti-pattern:
+
+```text
+확인하겠습니다.
+<tool call>
+```
+
+Correct:
+
+```text
+[Codex][gpt-5.5] → Tool: Bash
+[Codex][gpt-5.5] → Target: git status --short
+<tool call>
+```
+
 ### Common Violations to Avoid
 
 ```

package/templates/.claude/rules/SHOULD-memory-integration.md

@@ -361,7 +361,7 @@ MCP tools (searchable memory backends, episodic-memory) are **orchestrator-scope
 
 ### Session-End Self-Check (MANDATORY)
 
-(1) sys-memory-keeper updated MEMORY.md? (2) searchable memory save attempted when a backend is available? Both are required before confirming session-end to the user. See full self-check via Read tool.
+(1) sys-memory-keeper updated MEMORY.md? (2) searchable memory save attempted when a backend is available? (3) If `omcustomcodex-feedback` skill is active, prompt user to trigger it? All three are required before confirming session-end to the user. See full self-check via Read tool.
 
 <!-- DETAIL: Session-End Self-Check (MANDATORY)
 ```
@@ -376,10 +376,15 @@ MCP tools (searchable memory backends, episodic-memory) are **orchestrator-scope
 ║     YES → Continue (even if it failed)                           ║
 ║     NO  → ToolSearch + save now                                  ║
 ║                                                                   ║
+║  3. Is omcustomcodex-feedback skill available in this project?   ║
+║     YES → Ask user: "이번 세션 피드백을 omcustomcodex-feedback로 ║
+║          기록하시겠습니까?" — accept skip                        ║
+║     NO  → Skip                                                    ║
+║                                                                   ║
 ║  Note: episodic-memory auto-indexes conversations after session  ║
 ║  ends. No manual action needed — do NOT search as "verification" ║
 ║                                                                   ║
-║  BOTH steps must be completed before confirming to user.         ║
+║  ALL applicable steps must be completed before confirming to user.║
 ║  "Attempted" means called the tool — failure is OK, skipping     ║
 ║  is NOT.                                                          ║
 ╚══════════════════════════════════════════════════════════════════╝

package/templates/.claude/skills/systematic-debugging/SKILL.md

@@ -27,6 +27,7 @@ user-invocable: false
 4. **한 번에 하나의 가설만 검증한다.**
 5. **수정 시 "while I'm here" 리팩터링을 금지한다.**
 6. **수정 시도가 3번 실패하면 추가 패치 전에 구조적 문제를 의심한다.**
+7. **retry/cache/timeout을 변경하기 전에 false-fix 가능성을 점검한다.**
 
 이 과정을 어기는 것은 디버깅 실패로 본다.
 
@@ -64,6 +65,38 @@ user-invocable: false
 
 반드시 아래 순서로 진행한다.
 
+### Phase 0. Blocker Triage (Pre-Debug Gate)
+
+**Trigger**: When any external dependency, tool, or resource appears unavailable.
+
+Before declaring a task blocked or unsolvable, exhaust this checklist:
+
+| # | Workaround Path | Check |
+|---|----------------|-------|
+| 1 | Environment bypass | Can the dependency be bypassed in the current environment? |
+| 2 | Alternative tool | Is there an alternative tool, library, or approach? |
+| 3 | Partial solution | Can the task be partially completed without the dependency? |
+| 4 | Install/configure | Can the dependency be installed or configured now? |
+| 5 | Existing credentials | Are related tokens, auth files, or configs already present? |
+
+**Rules**:
+- Minimum 3 workaround paths MUST be explored before declaring "blocked"
+- Each explored path must be documented with outcome
+- "Session unsolvable" declarations MUST include the list of attempted workaround paths
+- If a workaround is found, proceed with debugging using that workaround
+
+**Output format**:
+```
+[Blocker Triage]
+├── Dependency: {what is unavailable}
+├── Path 1: {attempted} → {outcome}
+├── Path 2: {attempted} → {outcome}
+├── Path 3: {attempted} → {outcome}
+└── Verdict: {proceed with workaround N | genuinely blocked — reason}
+```
+
+If verdict is "genuinely blocked", escalate to user with full triage report. Do NOT silently abandon the task.
+
 ### Phase 1. Define The Problem
 
 먼저 문제를 축약한다.
@@ -286,3 +319,14 @@ This skill includes reference documents for specific debugging techniques:
 - `condition-based-waiting.md` — Replacing arbitrary delays with condition-based polling
 - `find-polluter.sh` — Bisection script for finding test pollution sources
 - `condition-based-waiting-example.ts` — Complete implementation of condition-based waiting utilities
+
+## Extended Phases
+
+These phase guides are mandatory when the debugging shape matches the trigger:
+
+| Phase guide | Trigger | Gate |
+|-------------|---------|------|
+| `phases/timeline-correlation.md` | Incident timing, deployment timing, or config drift may explain the failure | Correlate event time against code, deploy, config, data, and dependency timelines before patching. |
+| `phases/retry-cache-timeout-audit.md` | Proposed fix changes retry, cache, timeout, pooling, or backoff behavior | Prove the change fixes the root cause rather than suppressing symptoms. |
+| `phases/amplification-detection.md` | Traffic spikes, retry storms, queue growth, or cascading failures are possible | Identify amplification loops before increasing capacity or broadening retries. |
+| `phases/fault-injection.md` | The fix claims resilience against external failure modes | Inject the fault in a bounded environment and verify predicted behavior. |

package/templates/.claude/skills/systematic-debugging/phases/amplification-detection.md

@@ -0,0 +1,25 @@
+# Amplification Detection Phase
+
+Use this phase when the failure may cascade: retries, queues, background jobs, fan-out calls, polling loops, webhook delivery, cron overlap, or connection pools.
+
+## Required Checks
+
+1. Identify the trigger that starts the loop or fan-out.
+2. Count how many downstream operations one failing input can create.
+3. Check retry/backoff behavior and whether retries duplicate side effects.
+4. Check queue depth, worker concurrency, pool limits, and timeout alignment.
+5. Verify cancellation, dedupe, idempotency, and dead-letter behavior.
+
+## Output
+
+```text
+Amplification:
+- Trigger:
+- Fan-out factor:
+- Retry behavior:
+- Shared limit affected:
+- Dedupe/idempotency:
+- Verdict: {amplification present | no amplification evidence}
+```
+
+If amplification is present, stop widening retries or capacity until the loop has an owner and a guard.

package/templates/.claude/skills/systematic-debugging/phases/fault-injection.md

@@ -0,0 +1,31 @@
+# Fault Injection Phase
+
+Use this phase when a fix claims resilience against dependency failure, network failure, timeout, cancellation, corrupt input, clock skew, partial writes, or process restart.
+
+## Preconditions
+
+- The injected fault is bounded to local, test, or staging scope.
+- The expected behavior is written before running the injection.
+- Rollback is known and immediate.
+
+## Procedure
+
+1. State the fault and predicted behavior.
+2. Inject the smallest fault that exercises the claim.
+3. Record logs, exit code, response, retries, and cleanup behavior.
+4. Remove the fault and verify recovery.
+5. Convert the injection into a repeatable test when practical.
+
+## Output
+
+```text
+Fault Injection:
+- Fault:
+- Prediction:
+- Injection method:
+- Observed behavior:
+- Recovery:
+- Verdict: {claim proven | claim rejected | more instrumentation needed}
+```
+
+Do not run destructive or production fault injection without explicit authority.

package/templates/.claude/skills/systematic-debugging/phases/retry-cache-timeout-audit.md

@@ -0,0 +1,27 @@
+# Retry, Cache, Timeout Audit
+
+Use this phase before changing retries, caches, timeouts, pools, backoff, debounce, or rate limits.
+
+## Hard Gate
+
+A retry/cache/timeout change is invalid unless it explains why the original failure happened and proves the new behavior removes the root cause rather than hiding the symptom.
+
+## Audit Questions
+
+1. Is the proposed change reducing visible error rate without proving the failing operation now succeeds?
+2. Could it increase load, fan-out, duplicate side effects, or queue latency?
+3. Does it make the failure slower and harder to observe?
+4. Is the old timeout/cache/retry value actually wrong for the measured dependency behavior?
+5. Is there a smaller root-cause fix in input validation, ownership, ordering, or lifecycle?
+
+## Acceptable Evidence
+
+- Before/after traces showing the same request now reaches the intended success path.
+- Load or retry-count evidence proving amplification does not increase.
+- A failing guard that fails before the root-cause fix and passes after it.
+
+## Rejection Pattern
+
+```text
+Rejected: increased timeout/cache/retry | only suppresses the symptom; root cause remains unproven
+```

package/templates/.claude/skills/systematic-debugging/phases/timeline-correlation.md

@@ -0,0 +1,26 @@
+# Timeline Correlation Phase
+
+Use this phase when a failure has a meaningful time dimension: deployment time, config change time, traffic shift, data import, queue spike, cron run, dependency incident, or first customer report.
+
+## Required Steps
+
+1. Record the incident window in UTC and local time if available.
+2. List code, deploy, config, data, dependency, and traffic events around that window.
+3. Mark each event as before, during, or after first failure.
+4. Prefer events that happened before the first failure and changed the failing path.
+5. Write one falsifiable hypothesis that connects timing evidence to the symptom.
+
+## Output
+
+```text
+Timeline:
+- First failure:
+- Code/deploy events:
+- Config/data/dependency events:
+- Traffic or cron events:
+
+Hypothesis:
+<single root-cause hypothesis tied to the timeline>
+```
+
+Do not patch from chronology alone. Use the timeline to choose the next evidence-gathering step.

package/templates/.claude/statusline.sh

@@ -15,7 +15,13 @@
 #     "rate_limits": {                          (v2.1.80+, optional)
 #       "five_hour": { "used_percentage": 10, "resets_at": 1773979200 },
 #       "seven_day": { "used_percentage": 90, "resets_at": 1773979200 }
-#     }
+#     },
+#     "gh": {                                   (v2.1.145+, optional)
+#       "repo": "owner/repo",
+#       "pr_number": 160,
+#       "pr_state": "OPEN"
+#     },
+#     "agents": [ ... ]                         (v2.1.144+, optional)
 #   }
 
 # ---------------------------------------------------------------------------
@@ -61,14 +67,15 @@ fi
 
 # Debug logging for CTX investigation
 if [[ -n "${STATUSLINE_DEBUG}" ]]; then
-    printf '%s\n' "$json" >> "/tmp/.claude-statusline-debug-${PPID}.jsonl"
+    printf '%s\n' "$json" >> "/tmp/.codex-statusline-debug-${PPID}.jsonl"
 fi
 
 # ---------------------------------------------------------------------------
 # 4. Single jq call — extract all fields as TSV
-#    Fields: model_name, project_dir, ctx_pct, ctx_size, cost_usd, rl_5h_pct, rl_7d_pct, rl_5h_resets, rl_7d_resets
+#    Fields: model_name, project_dir, ctx_pct, ctx_size, cost_usd, rl_5h_pct, rl_7d_pct,
+#            rl_5h_resets, rl_7d_resets, gh_repo, gh_pr_number, gh_pr_state, agent_count
 # ---------------------------------------------------------------------------
-IFS=$'\t' read -r model_name project_dir ctx_pct ctx_size cost_usd rl_5h_pct rl_7d_pct rl_5h_resets rl_7d_resets <<< "$(
+IFS=$'\t' read -r model_name project_dir ctx_pct ctx_size cost_usd rl_5h_pct rl_7d_pct rl_5h_resets rl_7d_resets gh_repo gh_pr_number gh_pr_state agent_count <<< "$(
     printf '%s' "$json" | jq -r '[
         (.model.display_name // "unknown"),
         (.workspace.current_dir // ""),
@@ -78,14 +85,25 @@ IFS=$'\t' read -r model_name project_dir ctx_pct ctx_size cost_usd rl_5h_pct rl_
         (.rate_limits.five_hour.used_percentage // -1),
         (.rate_limits.seven_day.used_percentage // -1),
         (.rate_limits.five_hour.resets_at // -1),
-        (.rate_limits.seven_day.resets_at // -1)
+        (.rate_limits.seven_day.resets_at // -1),
+        (if (.gh.repo // "") == "" then "_" else .gh.repo end),
+        (if (.gh.pr_number // "") == "" then "_" else (.gh.pr_number | tostring) end),
+        (if (.gh.pr_state // "") == "" then "_" else .gh.pr_state end),
+        (if (.agents | type) == "array" then (.agents | length) else 0 end)
     ] | @tsv'
 )"
 
+[[ "$gh_repo" == "_" ]] && gh_repo=""
+[[ "$gh_pr_number" == "_" ]] && gh_pr_number=""
+[[ "$gh_pr_state" == "_" ]] && gh_pr_state=""
+if ! [[ "$agent_count" =~ ^[0-9]+$ ]]; then
+    agent_count=0
+fi
+
 # ---------------------------------------------------------------------------
 # 4b. Cost & context data bridge — write to temp file for hooks
 # ---------------------------------------------------------------------------
-COST_BRIDGE_FILE="/tmp/.claude-cost-${PPID}"
+COST_BRIDGE_FILE="/tmp/.codex-cost-${PPID}"
 _tmp="${COST_BRIDGE_FILE}.tmp.$$"
 printf '%s\t%s\t%s\t%s\t%s\t%s\t%s\n' "$cost_usd" "$ctx_pct" "$(date +%s)" "$rl_5h_pct" "$rl_7d_pct" "$rl_5h_resets" "$rl_7d_resets" > "$_tmp" 2>/dev/null && mv -f "$_tmp" "$COST_BRIDGE_FILE" 2>/dev/null || true
 
@@ -232,7 +250,12 @@ fi
 # 8. PR number — cached by branch to avoid gh call on every refresh
 # ---------------------------------------------------------------------------
 pr_display=""
-if [[ -n "$git_branch" ]] && command -v gh >/dev/null 2>&1; then
+if [[ -n "$gh_pr_number" ]]; then
+    pr_display="PR #${gh_pr_number}"
+    if [[ -n "$gh_pr_state" && "$gh_pr_state" != "OPEN" ]]; then
+        pr_display="${pr_display} ${gh_pr_state}"
+    fi
+elif [[ -n "$git_branch" ]] && command -v gh >/dev/null 2>&1; then
     cache_file="/tmp/statusline-pr-${project_name}"
     cached_branch=""
     cached_pr=""
@@ -360,6 +383,12 @@ if [[ -n "$wl_display" ]]; then
     wl_segment=" | ${wl_color}${wl_display}${COLOR_RESET}"
 fi
 
+# Build the active agent count segment from statusline JSON when available.
+agent_segment=""
+if [[ "$agent_count" -gt 0 ]]; then
+    agent_segment=" | A:${agent_count}"
+fi
+
 # Build the RTK segment from the session-env bridge if available.
 rtk_segment=""
 env_status_file="/tmp/.codex-env-status-${PPID}"
@@ -380,22 +409,24 @@ if [[ -f "$env_status_file" ]]; then
 fi
 
 if [[ -n "$git_branch" ]]; then
-    printf "${cost_color}%s${COLOR_RESET} | %s | %s%s%s%s%s | ${ctx_color}%s${COLOR_RESET}\n" \
+    printf "${cost_color}%s${COLOR_RESET} | %s | %s%s%s%s%s%s | ${ctx_color}%s${COLOR_RESET}\n" \
         "$cost_display" \
         "$project_name" \
         "$branch_display" \
         "$pr_segment" \
         "$rl_segment" \
         "$wl_segment" \
+        "$agent_segment" \
         "$rtk_segment" \
         "$ctx_display"
 else
-    printf "${cost_color}%s${COLOR_RESET} | %s%s%s%s%s | ${ctx_color}%s${COLOR_RESET}\n" \
+    printf "${cost_color}%s${COLOR_RESET} | %s%s%s%s%s%s | ${ctx_color}%s${COLOR_RESET}\n" \
         "$cost_display" \
         "$project_name" \
         "$pr_segment" \
         "$rl_segment" \
         "$wl_segment" \
+        "$agent_segment" \
         "$rtk_segment" \
         "$ctx_display"
 fi

package/templates/AGENTS.md.en

@@ -135,7 +135,7 @@ project/
 |   +-- contexts/                # Context files (ecomode)
 +-- .agents/
 |   +-- skills/                  # Installed skills (123 directories)
-+-- guides/                      # Reference docs (48 topics)
++-- guides/                      # Reference docs (50 topics)
 ```
 
 ## Orchestration

package/templates/AGENTS.md.ko

@@ -135,7 +135,7 @@ project/
 |   +-- contexts/                # 컨텍스트 파일 (ecomode)
 +-- .agents/
 |   +-- skills/                  # 설치된 스킬 (123 디렉토리)
-+-- guides/                      # 레퍼런스 문서 (48 토픽)
++-- guides/                      # 레퍼런스 문서 (50 토픽)
 ```
 
 ## 오케스트레이션

package/templates/CLAUDE.md

@@ -120,7 +120,7 @@ project/
 |   +-- contexts/                # 컨텍스트 파일 (ecomode)
 +-- .agents/
 |   +-- skills/                  # 스킬 (123 디렉토리)
-+-- guides/                      # 레퍼런스 문서 (48 토픽)
++-- guides/                      # 레퍼런스 문서 (50 토픽)
 ```
 
 ## 오케스트레이션

package/templates/CLAUDE.md.en

@@ -137,7 +137,7 @@ project/
 |   +-- rules/                   # Global rules (22 files)
 |   +-- hooks/                   # Hook scripts (security, validation, HUD)
 |   +-- contexts/                # Context files (4 files)
-+-- guides/                      # Reference docs (48 topics)
++-- guides/                      # Reference docs (50 topics)
 ```
 
 ## Orchestration

package/templates/CLAUDE.md.ko

@@ -137,7 +137,7 @@ project/
 |   +-- rules/                   # 전역 규칙 (22 파일)
 |   +-- hooks/                   # 훅 스크립트 (보안, 검증, HUD)
 |   +-- contexts/                # 컨텍스트 파일 (4 파일)
-+-- guides/                      # 레퍼런스 문서 (48 토픽)
++-- guides/                      # 레퍼런스 문서 (50 토픽)
 ```
 
 ## 오케스트레이션

package/templates/README.md

@@ -48,11 +48,11 @@ templates/
 |   +-- agents/                       # agent definitions (49 files)
 |   +-- skills/                       # skill modules (123 SKILL.md files)
 |   +-- rules/                        # global rules (22 files)
-|   +-- hooks/                        # hook registry and scripts (38 scripts)
+|   +-- hooks/                        # hook registry and scripts (40 scripts)
 |   +-- contexts/                     # context files
 |   +-- ontology/                     # ontology and routing metadata
 |   +-- schemas/                      # tool input schemas
-+-- guides/                           # reference docs (48 topics)
++-- guides/                           # reference docs (50 topics)
 ```
 
 ## Components
@@ -77,13 +77,13 @@ Reusable workflow and reference skill modules. During Codex installation these l
 
 Global agent behavior rules. During Codex installation these land under `.codex/rules/`.
 
-### Guides (48)
+### Guides (50)
 
 `templates/guides/*/`
 
 Reference documentation directories copied to installed projects as `guides/`.
 
-### Hooks (38)
+### Hooks (40)
 
 `templates/.claude/hooks/scripts/*.sh`
 

package/templates/guides/agent-teams/troubleshooting.md

@@ -0,0 +1,53 @@
+# Agent Teams Shutdown and tmux Fallback Troubleshooting
+
+This guide ports the old Claude Code shutdown flow into Codex/OMX terms. Use it when an Agent Teams session stops making forward progress during shutdown, cleanup, or handoff.
+
+## Typical Failure Signs
+
+| Symptom | Likely cause | Action |
+| --- | --- | --- |
+| `TeamDelete` refuses to complete | One or more members are still active | Send a final shutdown request, then retry once |
+| Idle notifications repeat without exit | A member saw the request but did not stop | Wait briefly, then fall back to stale-session cleanup |
+| The team looks done but the pane is still attached | The worker is still owned by tmux | Reclaim the owned tmux pane or session before declaring cleanup complete |
+| Progress stops after a member blocks | The member is waiting on a dependency | Reassign or wait silently instead of polling forever |
+
+## Recovery Order
+
+1. Send one explicit shutdown message to the team member or team lead.
+2. Wait for a short, fixed interval.
+3. Try `TeamDelete` again.
+4. If `TeamDelete` still fails and the session is clearly stale, clean up the owned tmux pane or session.
+5. Re-check `.omx/state/` and confirm the active mode is gone.
+
+## Fallback Rules
+
+- Prefer graceful shutdown first: `SendMessage` with a shutdown request, then `TeamDelete`.
+- Use tmux fallback only for stale local cleanup, not as the default path.
+- Do not kill a pane or session that still contains live user work.
+- After fallback cleanup, clear any stale `omx` runtime state that still claims the team is active.
+
+## Codex/OMX Surface Map
+
+| Need | Default surface | Compatibility note |
+| --- | --- | --- |
+| Ask the team to stop | `SendMessage` | Legacy Claude Code shutdown flows may use analogous `/bg` or background-session signals |
+| Remove a finished team | `TeamDelete` | Treat refusal as a state problem, not as permission to spin forever |
+| Kill a stale worker pane | OMX-managed `tmux` session or pane | Claude-specific socket names are compatibility-only references |
+| Clear lingering session state | `.omx/state/` and related runtime files | Do not rely on the pane alone as the source of truth |
+
+## Example Recovery Sequence
+
+```text
+1. SendMessage(team-member, "shutdown request")
+2. Wait for the member to stop producing work
+3. TeamDelete(team)
+4. If TeamDelete still reports active members and the session is stale, kill the owned tmux pane
+5. Re-run the state check and confirm no active OMX mode remains
+```
+
+## Escalate When
+
+- The pane or session is not owned by the current task.
+- Cleanup would interrupt active user work.
+- The same stale team keeps reappearing after cleanup.
+- A shared infra tmux socket or background process is involved.

package/templates/guides/autonomous-challenge-lessons/README.md

@@ -0,0 +1,43 @@
+# Autonomous Challenge Lessons
+
+This guide captures repeatable lessons from long autonomous runs where the agent must inspect an existing challenge environment, produce a fix, and verify the result without frequent human steering.
+
+## Start With Ground Truth
+
+Before implementing a guessed mechanism, check whether the environment already contains an answer artifact, compiled fix, reference binary, fixture, or expected-output file.
+
+Required first-pass questions:
+
+1. Is there a supplied fix artifact, golden output, or reference implementation?
+2. Which runtime version and mapping namespace are actually present?
+3. Which identifiers are proven by code inspection rather than inferred from memory?
+4. Which launcher or environment flags are being used, and what do they mean?
+
+## Repeated Failure Discipline
+
+If the same critical error appears twice, stop repeating the launch or tool call. Re-check the option, permission, process state, or single-instance constraint that may make the command invalid.
+
+Examples:
+
+- Tool permission denial: do not repeat the exact same tool call; switch evidence path.
+- Launcher flag failure: read the flag meaning before another launch.
+- Single-instance process collision: check and clean the process state before relaunch.
+- Background command output loss: locate the output file or rerun through a managed log path.
+
+## Parallel Work Heuristic
+
+When a single command is about to process dozens of independent files, downloads, or checks, split it into bounded parallel lanes instead of making one long opaque shell run.
+
+Use this when:
+
+- There are about 30 or more independent units.
+- Failures can be isolated by chunk.
+- Results can be merged deterministically.
+
+## QA Evidence
+
+QA reports must quote identifiers from the target code before using them. Selectors, `data-testid` values, mapping names, CLI flags, and config keys are not valid unless read or grepped from the project.
+
+## GUI Verification
+
+For visual or interactive tasks, collect direct browser, screenshot, or runtime evidence when possible. If only indirect evidence is available, label it as indirect and explain what could not be captured.

package/templates/guides/claude-code/15-version-compatibility.md

@@ -2,6 +2,57 @@
 
 This guide records Claude Code release-note impact that affects the Claude compatibility template. The Codex-native runtime still uses `.codex/**` and OMX as the primary surface.
 
+## v2.1.146
+
+Published: 2026-05-21.
+
+Source: upstream oh-my-customcode #1205, Codex port #1364.
+
+| Change | Impact on oh-my-customcodex | Action |
+|--------|------------------------------|--------|
+| `/simplify` was renamed to `/code-review` and accepts effort levels such as `/code-review high` | Native Claude command naming is now closer to review workflows, but this package still exposes its own `dev-review` skill. | No runtime rename. Keep user-facing docs clear that `dev-review` is the package skill and `/code-review` is the native Claude command. |
+| Auto mode no longer suppresses `AskUserQuestion` when the user or a skill explicitly relies on it | Ambiguity-gated compatibility workflows can ask explicit questions even in auto mode. | No Codex tool change. Keep `request_user_input`/question usage limited to genuinely branching cases. |
+| MCP `resources/list`, `resources/templates/list`, and `prompts/list` pagination was fixed | Large memory or ontology MCP servers are less likely to hide resources after page 1. | No package change; treat complete paginated MCP lists as more reliable evidence. |
+| `CLAUDE_CODE_SUBAGENT_MODEL` is forwarded to child processes in multi-agent sessions | Claude compatibility sessions with model env overrides now preserve child-process model intent. | No Codex model override. Codex-native child agents still follow repo model routing and inherited defaults. |
+| `/background` accepts skill-only or custom-slash-only input and background sessions preserve granted tool permissions | Long-running Claude compatibility sessions are less likely to stall on already granted permissions. | No Codex change. Keep permission expectations explicit in workflow prompts. |
+| Agent SDK streaming end-of-session exception was fixed | Agent SDK plugin experiments should be less noisy at stream completion. | Monitor only; no package change. |
+
+## v2.1.145
+
+Published: 2026-05-19.
+
+Source: upstream oh-my-customcode #1191, Codex port #1353.
+
+| Change | Impact on oh-my-customcodex | Action |
+|--------|------------------------------|--------|
+| Statusline input includes structured GitHub fields such as `gh.repo`, `gh.pr_number`, and `gh.pr_state` | Removes the need to call `gh pr view` on every refresh when Claude compatibility statusline JSON already carries PR context. | Ported. `statusline.sh` now prefers native `gh.*` fields and falls back to the cached `gh pr view` path only when they are absent. |
+| Additional statusline fields may be empty strings | Empty fields can collapse TSV parsing if not normalized. | Ported. Empty native GitHub fields are normalized before Bash reads them. |
+| Stability fixes for statusline and background sessions are additive | No Codex runtime change beyond template compatibility. | Keep `.codex/**` behavior primary and mirror compatibility docs. |
+
+## v2.1.144
+
+Published: 2026-05-18.
+
+Source: upstream oh-my-customcode #1187, Codex port #1349.
+
+| Change | Impact on oh-my-customcodex | Action |
+|--------|------------------------------|--------|
+| `claude agents --json` exposes structured background-agent state | Claude compatibility statusline and monitoring can show active agent counts without parsing display text. | Ported. Statusline JSON `agents` arrays render as `A:N` when active agents exist. |
+| Stop/SubagentStop input can include `background_tasks` and `session_crons` | Session-end hooks can detect dangling background work and cron state. | Ported. `session-reflection.sh` records counts and summaries when those fields are present. |
+| Background-agent status handling became more reliable | Reduces false stale-agent diagnostics for Claude compatibility users. | Keep existing Codex/OMX agent tracking and treat Claude JSON as optional compatibility evidence. |
+
+## v2.1.143
+
+Published: 2026-05-17.
+
+Source: upstream oh-my-customcode #1166, Codex port #1348.
+
+| Change | Impact on oh-my-customcodex | Action |
+|--------|------------------------------|--------|
+| Hook/session lifecycle payloads became richer for background work | The compatibility template can capture more useful session-end evidence without blocking shutdown. | Ported through the advisory `session-reflection.sh` Stop/SubagentStop hook. |
+| Background session handling received additional fixes | Helps Claude compatibility workflows that run long-lived agents. | No Codex runtime change; document behavior and keep OMX-native orchestration as primary. |
+| Release-note changes are Claude-template oriented | The package must avoid redesigning Codex-native flow for Claude-only payload additions. | Mirror the compatibility guide and add tests that lock template/source docs together. |
+
 ## v2.1.142
 
 Published: 2026-05-14.

package/templates/guides/claude-code-tracking.md

@@ -0,0 +1,51 @@
+# Background Agent Progress Tracking
+
+This is the Codex/OMX replacement for the old Claude Code background-agent tracking pattern. Use it when a subagent, team member, or delegated task keeps running while the main conversation moves on.
+
+## What To Track
+
+| Field | Purpose | Suggested source |
+| --- | --- | --- |
+| `agent_id` | Identify the worker unambiguously | Team member label or agent name |
+| `task` | Record what the worker is doing | The delegated prompt or issue title |
+| `state` | Show the current lifecycle stage | `queued`, `running`, `blocked`, `done`, `cleaned` |
+| `last_update` | Detect stale work | Timestamp from the latest status write |
+| `owner` | Tie progress to the current session | Branch, run, or team lead |
+| `next_action` | Make the next step obvious | `wait`, `retry`, `cleanup`, or `handoff` |
+
+## Preferred Surfaces
+
+- `.omx/state/` for durable session state.
+- `.omx/notepad.md` for lightweight progress notes.
+- `.omx/logs/` for execution traces and failure evidence.
+- `tracker-checkpoint` when you need a dedicated checkpoint agent to own progress bookkeeping.
+
+## Minimal Progress Loop
+
+1. Register the background task before it starts.
+2. Write a start record with the task and owner.
+3. Update the state when the worker changes phase.
+4. Mark the worker blocked instead of polling forever.
+5. Mark the worker done, then clean stale state if anything remains attached.
+
+## Recommended Status Format
+
+```text
+agent: tracker-checkpoint
+task: mirror rule and guide updates
+state: running
+last_update: 2026-05-24T12:00:00+09:00
+owner: release/v0.5.2-auto-dev
+next_action: wait_for_mirror_sync
+```
+
+## Staleness Rule
+
+If a background worker stops updating, treat it as stale after a short, defined window. Do not keep polling indefinitely. Either re-plan the task, hand it off, or clean it up.
+
+## Codex/OMX Notes
+
+- The main conversation should read the newest state file, not a stale log excerpt, before deciding what to do next.
+- If the worker is a team member, the progress record should make the team lead and branch obvious.
+- A background task that has already completed should not keep emitting progress noise.
+- Legacy Claude Code background-session references can remain as compatibility notes, but the default progress surface here is `.omx/state/`.

package/templates/guides/index.yaml

@@ -8,6 +8,18 @@ guides:
     source:
       type: internal
 
+  - name: agent-teams
+    description: Agent Teams shutdown and tmux fallback troubleshooting for Codex/OMX sessions
+    path: ./agent-teams/troubleshooting.md
+    source:
+      type: internal
+
+  - name: claude-code-tracking
+    description: Background agent progress tracking and stale-state handling for Codex/OMX sessions
+    path: ./claude-code-tracking.md
+    source:
+      type: internal
+
   # Frontend
   - name: impeccable-design
     description: AI design language reference — typography, color, motion, and UX writing for production-grade UI