PostToolUse diagnostics timeout when TypeScript diagnostics remain empty

Start by reading plugins/omo/components/lsp/src/codex-hook.ts and the LSP daemon source that produces the bundled plugins/omo/components/lsp-daemon/dist/cli.js; the issue identifies the freshness wait and TypeScript diagnostic behavior. Check the daemon’s existing tests and add regression coverage for repeated valid edits with empty diagnostics, plus the syntax error and repair transition. Done when PostToolUse returns current empty diagnostics without timing out, while errors appear and clear correctly.

Summary

The OMO PostToolUse diagnostics hook blocks repeated edits when TypeScript Language Server has an unchanged empty diagnostics set. The server correctly suppresses duplicate empty publishes, but OMO waits for a new publish after every edit and reports a 3-second freshness timeout.

Environment

• LazyCodex: 5.1.40
• Codex CLI: 0.163.0
• OS: macOS 25.5, arm64
• Install: installed OMO plugin cache
• LSP: typescript-language-server 6.0.2 with TypeScript 6.0.3; TypeScript configured for .mjs

Repository Decision

• Target: code-yeongyu/lazycodex
• Why: the failure is in OMO's bundled LSP daemon freshness contract and PostToolUse integration. Fresh upstream Codex has no OMO hook/daemon implementation; current Codex source search contains no lsp-daemon, omo-lsp, or diagnosticsFreshnessTimeout.
• LazyCodex evidence: latest source is bca7c59b870b1d468e7d2ea869ef263661a2c8d8. Its PostToolUse path is plugins/omo/components/lsp/src/codex-hook.ts; the shipped generated daemon at plugins/omo/components/lsp-daemon/dist/cli.js requires a fresh publish or pull result for the current document generation (lines 2191-2203 and 3540-3602).
• Upstream Codex comparison: a fresh openai/codex sync at d138398cef7d49e46fe33f1d0ddbd2ca0ed16aa4 has no corresponding hook or daemon code.
• Existing issue check: no matching issue found. #90 concerns a daemon bootstrap regression that dropped diagnostics; #154 concerns paths outside session CWD. This is a distinct empty-set freshness timeout.

Reproduction

Using an installed OMO 5.1.40 plugin and an active TypeScript LSP client rooted at a checkout:

1. Create an ignored JS file inside the checkout, for example .omo/evidence/lsp-probe.mjs.
2. For each value below, write export const value = N;\n to the same file and invoke the shipped hook CLI from the checkout root with the corresponding PostToolUse payload:

PLUGIN_ROOT="$HOME/.codex/plugins/cache/sisyphuslabs/omo/5.1.40"
ROOT="/path/to/checkout"
FILE="$ROOT/.omo/evidence/lsp-probe.mjs"
mkdir -p "$(dirname "$FILE")"
for n in 1 2 3; do
  printf 'export const value = %s;\n' "$n" > "$FILE"
  printf '{"session_id":"lsp-repro-%s","tool_name":"Edit","tool_input":{"path":"%s"},"tool_response":{"success":true}}' "$n" "$FILE" |
    node "$PLUGIN_ROOT/components/lsp/dist/cli.js" hook post-tool-use
done

3. The first call opens/warms the file; subsequent calls are content-only edits that keep diagnostics empty.

Expected Behavior

The hook should return the authoritative current diagnostics (empty for these valid edits) or a clearly non-blocking unavailable result. It should not block an otherwise valid edit just because the server has no changed diagnostic notification to send.

Actual Behavior

On the active Merge Gate worktree, the repeated real PostToolUse hook returned no output for the first edit (685 ms), then blocked edits 2 and 3 after 3069 and 3067 ms:

{"decision":"block","reason":"LSP diagnostics after editing .../.omo/evidence/lsp-probe.mjs:\n\nTimed out waiting for fresh diagnostics for .../.omo/evidence/lsp-probe.mjs within 3000ms."}

A controlled transition on the same real hook returned syntax errors for an invalid JS edit in 659 ms, then returned empty diagnostics after the fix in 683 ms. Thus diagnostic-set changes are published and processed; repeated empty sets are the failing case.

Evidence

• Installed plugin metadata: OMO 5.1.40, bundled daemon 0.1.0; npm view oh-my-openagent version dist-tags.latest --json reports latest 5.1.40, so no newer supported host release was available.
• Raw TypeScript LSP protocol probe on a project JS file: didOpen published []; after didChange to a different valid source with the same empty diagnostics, no new publishDiagnostics arrived within 10 seconds.
• That probe explicitly advertised textDocument.publishDiagnostics.versionSupport: true; the notification was still suppressed.
• A workspace/executeCommand using the documented typescript.tsserverRequest command for syntacticDiagnosticsSync and semanticDiagnosticsSync returned body: [] for the edited snapshot in about 1.2 seconds.
• TypeScript Language Server v6.0.2 source confirms the behavior in src/diagnosticsManager.ts: FileDiagnostics.update returns early when the previous and new diagnostic arrays for a category are both empty (lines 29-36), independent of client capabilities: source at v6.0.2.
• OMO's published daemon bundle shows the waiting side: resolvePushDiagnostics and generation checks, and the push-only timeout path.
• Raw hook and protocol captures are retained locally at /tmp/merge-gate-repair-trigger-evidence/active-worktree-hook-roundtrip.json, active-diagnostic-transition.json, and syncdiag-probe.json.

Root Cause

For a client without pull diagnostics, OMO treats a diagnostics snapshot as current only if it receives a publish at or after the document generation. TypeScript Language Server suppresses a repeated empty diagnostic category before publishing. After a successful initial empty publish, a later edit that keeps the diagnostics empty increments OMO's document generation but not its publish generation; with pull unsupported, the daemon waits until its 3000 ms deadline and reports a freshness timeout. Advertising versionSupport cannot help: TSLS's duplicate-empty early return does not inspect that capability, and the raw probe reproduced the timeout with it enabled.

Proposed Fix

Add a current-snapshot path for TypeScript Language Server when pull diagnostics are unsupported, using its advertised/documented typescript.tsserverRequest command with syntacticDiagnosticsSync and semanticDiagnosticsSync; map and combine those results for the current document version before returning. Do not treat a stale pre-edit publish as current or assume unchanged diagnostics without a fresh result. Implement this in the underlying OMO LSP daemon/core source and regenerate the bundled distribution rather than patching generated dist files alone.

Verification Plan

• Regression: valid JS, then at least two content-only edits that keep diagnostics empty; each real PostToolUse invocation returns empty diagnostics without a freshness timeout.
• Error transition: valid JS → syntax error → repaired JS; the error appears on the broken edit and clears on repair.
• Existing behavior: a server with pull diagnostics continues to use versioned current-snapshot results; verify diagnostic errors are neither dropped nor stale.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated