Skip to content

Refactor bridge config and runtime status#52

Merged
axeldelafosse merged 12 commits intomainfrom
codex/bridge-runtime-cleanup
Mar 30, 2026
Merged

Refactor bridge config and runtime status#52
axeldelafosse merged 12 commits intomainfrom
codex/bridge-runtime-cleanup

Conversation

@axeldelafosse
Copy link
Copy Markdown
Owner

Summary

  • centralize bridge server/config helpers and add a dedicated Claude bridge registration helper
  • unify Claude bridge naming across tmux and non-tmux paired flows
  • enrich bridge status/runtime status fields and add bridge coverage for the new naming and delivery modes

Verification

  • bun test tests/loop/bridge.test.ts
  • bun test tests/loop/tmux.test.ts tests/loop/paired-loop.test.ts tests/loop/runner.test.ts tests/loop/claude-sdk-server.test.ts tests/loop/codex-app-server.test.ts
  • bun run check
  • bun test

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors Claude channel server registration and status reporting by introducing a dedicated registration module and expanding the bridge status interfaces with detailed delivery modes. The runtime logic is updated to utilize these enhanced status fields, and configuration building is consolidated. Feedback was provided to improve the robustness of new tests by parsing JSON output instead of using string-based assertions.

Comment on lines +957 to +962
const status = toolText(result.stdout, 1);
expect(status).toContain('"claudeBridgeMode": "mcp-config"');
expect(status).toContain('"claudeChannelServer": "loop-bridge-7"');
expect(status).toContain('"codexDeliveryMode": "app-server"');
expect(status).toContain('"hasCodexRemote": true');
expect(status).toContain('"hasLiveTmuxSession": false');
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The test assertions on the status string are brittle as they rely on specific string formatting. Since agent CLIs in paired tmux runtimes should use newline-delimited JSON on stdout, it is more robust to parse the JSON and assert on the properties using toMatchObject. This prevents the test from failing due to unrelated formatting changes and aligns with the requirement for NDJSON communication.

Suggested change
const status = toolText(result.stdout, 1);
expect(status).toContain('"claudeBridgeMode": "mcp-config"');
expect(status).toContain('"claudeChannelServer": "loop-bridge-7"');
expect(status).toContain('"codexDeliveryMode": "app-server"');
expect(status).toContain('"hasCodexRemote": true');
expect(status).toContain('"hasLiveTmuxSession": false');
const statusJson = JSON.parse(toolText(result.stdout, 1));
expect(statusJson).toMatchObject({
claudeBridgeMode: "mcp-config",
claudeChannelServer: "loop-bridge-7",
codexDeliveryMode: "app-server",
hasCodexRemote: true,
hasLiveTmuxSession: false,
});
References
  1. When communicating between agents in a paired tmux runtime, use newline-delimited JSON on stdout for agent CLIs, as Content-Length framing can break registration/connection.

@axeldelafosse axeldelafosse marked this pull request as ready for review March 30, 2026 03:22
@axeldelafosse axeldelafosse merged commit c6d2a1c into main Mar 30, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant