Keep normal Xcode route recovery out of default logs

[lynnswap]

Purpose

A GUI Xcode process with no open workspace is a normal missing route while another route can continue serving tools. After the partial-catalog behavior introduced in #192, missing catalogs converge in the background, but route-local timeouts still emitted a proxy-wide Xcode tools are unavailable warning and repeated retry telemetry at the default log level.

This made healthy client sessions appear degraded and continuously polluted the proxy's default stderr output. This PR aligns default-visible logging with client-visible availability without changing process discovery, retry cadence, or background catalog completion.

Changes

• Move tools-unavailable warning deduplication from individual bridge recovery state to the service-level catalog authority. The warning is emitted only when no usable catalog exists, at most once per continuous outage, and a successful catalog commit rearms it.
• Consume the warning incident only at the actual emission boundary, so a delayed or abandoned bridge replacement cannot suppress a later actionable warning.
• Keep route activation attempts, timeouts, retries, bridge-pool recovery, and readiness backoff available as debug telemetry instead of printing them at the default info level.
• Move routine HTTP connection, SSE connection, request, and response access events to debug, including expected protocol-level 4xx responses such as an unknown or terminated session.
• Update the logging and troubleshooting contracts, including the existing stale statement that missing process catalogs do not refresh in the background.
• Add regression coverage for partial-catalog warning suppression, proxy-wide incident deduplication and rearming, and HTTP access-log severity.

Review focus

• The service-level catalog authority is the single owner of whether an unavailable warning may be emitted; a route-local timeout does not imply a proxy-wide outage.
• A suppressed timeout does not consume the warning incident, and warning consumption happens only immediately before the warning is logged.
• info remains reserved for bounded lifecycle transitions such as startup, route membership, and a catalog becoming available. Detailed recovery and access telemetry remains available with MCP_LOG_LEVEL=debug.

Testing

• scripts/check.sh
  • complete package test suite
  • XcodeMCPProcessRuntimeTests (24 tests)
  • ProxyStdioAdapterTests (13 tests)
• swift test --no-parallel --filter 'ControlPlaneAuthorityTests|HTTPResponseWriterLoggingTests' -Xswiftc -strict-concurrency=minimal
• swift test --no-parallel --filter 'ProxyLoggingTests|UpstreamReadinessTests|HTTPHandlerTests|HTTPResponseWriterLoggingTests' -Xswiftc -strict-concurrency=minimal
• git diff --check
• Branch-wide Codex review against the final diff: clean, 0 findings
• Not run: a live multi-Xcode smoke test. The change is covered at the catalog-authority and logger boundaries without starting or stopping the user's Xcode processes.

Related context

• Follow-up to Multi-Xcode tool discovery waits for a workspace-less process #191 and Keep usable Xcode routes responsive when sibling processes stall #192.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
🔒 Security Review	✅ Completed 2026-09-03T02:05:44.140454Z	14ab77c	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.