CLI-215 Add Codex Plugin integrating with SonarQube

[kussberg]

No description provided.

[hashicorp-vault-sonar-prod]

CLI-215

[sonar-review-alpha]

Summary

Adds sonar integrate codex command to enable OpenAI Codex integration with SonarQube, providing feature parity with the existing Claude integration. The implementation includes secrets scanning hooks and MCP configuration support. To reduce duplication, common integration logic is extracted to _common/ and reused by both agents. The feature includes comprehensive unit (350 tests) and integration tests (1541 tests), plus extended migration logic to handle hook artifacts for both Claude and Codex.

What reviewers should know

Start here: Review src/cli/commands/integrate/codex/index.ts for the main Codex integration flow, which mirrors the Claude integration structure.

Architecture overview:

• Shared logic lives in src/cli/commands/integrate/_common/ (integrate-configuration.ts, sqaa-entitlement.ts, etc.) and is used by both Claude and Codex
• Agent-specific code stays separate: codex/ and claude/ directories contain hooks, health checks, and configuration handling
• Both agents use the same ~/.USER_AGENT directory pattern (.codex vs .claude) with identical subdirectory structures

Testing: Look at tests/integration/specs/integrate/codex.test.ts (1541 lines) for comprehensive integration scenarios. Unit tests are in tests/unit/integrate-codex.test.ts. The old test structure was reorganized and consolidated.

Non-obvious details:

• The --global flag installs to ~/.codex instead of the project .codex/, same as Claude's --global behavior
• Migration logic (src/lib/migration.ts) now handles artifacts for both agents; state access uses optional chaining since test configs may omit one agent
• Both agents support project discovery, token repair, health checks, and SQAA entitlement validation through the shared integration code

Watch for: The refactoring assumes state files may contain only partial agent configs (e.g., Codex without Claude). The migration functions defensively check agent existence before accessing hooks.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonarqube-agent]

Remediation Agent Summary 📊

🤖 To review: Fixes are ready for 1 of 1 issues found.

💪 Save time: Applying these fixes could save you an estimated 5 minutes.

Suggested fixes (1)

Quality

Issue

Maintainability 🟡 Low

`String.raw` should be used to avoid escaping ``. Why is this an issue? An issue is raised when a string literal contains escaped backslashes (\\) that could be simplified using String.raw template literals. Why is this an issue? String literals with escaped backslashes can be difficult to read and maintain. Each backslash character must be escaped with another backslash, creating sequences like \\ that are hard to interpret at a glance. This problem is particularly common when working with: File paths on Windows systems Regular expression patterns LaTeX or other markup that uses backslashes Any string content that naturally contains backslash characters The String.raw template literal provides a cleaner alternative. It treats backslashes literally without requiring escaping, making the code more readable and less error-prone. The intent becomes clearer, and there’s less chance of accidentally missing or adding extra backslashes during maintenance. What is the potential impact? Using escaped backslashes instead of String.raw reduces code readability and increases the likelihood of errors when maintaining string literals. While this doesn’t cause runtime issues, it makes the codebase harder to understand and modify correctly. How to fix? Replace string literals containing escaped backslashes with String.raw template literals. The backslashes inside the template literal don’t need to be escaped. Non-compliant code example View this code on SonarQube Cloud Compliant code example View this code on SonarQube Cloud Documentation eslint-plugin-unicorn - Rule prefer-string-raw String.raw - MDN Web Docs - Official documentation for the String.raw template literal tag Template literals - MDN Web Docs - Comprehensive guide to template literals in JavaScript View this issue in SonarQube Cloud

🤖 Agent created PR #137

💡 Got issues in your backlog? Let the agent fix them for you.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 Dependency risks

Measures
0 Security Hotspots
87.2% Coverage on New Code
1.5% Duplication on New Code

See analysis details on SonarQube Cloud

[sonar-review-alpha]

Conclusion\n\nSmall scoped commit — the string-escaping refactor is correct and the shared deduplicate helper is a genuine improvement. Security hotspot [dos] at codex-config.ts:136 (flagged inside stripMcpServersSonarqubeBlock) is safe: the regex /^\\[[^\\]]+\\]\\s*$/ has no nested or overlapping quantifiers, executes linearly in line length, and operates on a single line of a local user-controlled config file — there is no ReDoS attack surface.

🗣️ Give feedback

[fpoulin]

Hi @kussberg,

Thank you for the incredible effort you put into this Codex integration. This is an impressive body of work that serves as a valuable Proof of Concept, validating many of the strategic directions we intend to follow. While we appreciate the initiative and the logic shown here, we have decided not to move forward with this PR and will be closing it for the following reasons:

• Architectural Conflict: We are currently implementing a foundational re-architecture of our filesystem I/O. This PR introduces a different architectural approach and a significant rewrite of the existing Claude integration that conflicts with our planned internal changes and would create substantial technical debt.
• Reviewability and Scope: At 6k+ lines, this PR exceeds our limit for external contributions. To ensure long-term maintainability and security, we require large features to be broken down into small, modular slices and coordinated with the team beforehand.
• Technical Dependencies: The PR introduces unannounced external dependencies (such as jq) and lacks documentation for platform-specific gaps, such as the Windows skip behavior for hooks.

Moreover, our early prototyping has revealed several limitations in the Codex platform itself—including a lack of Windows hook support (which your implementation circumvents in a somewhat fragile way), restricted Read/Write matchers, and silent failures in the UserPromptSubmit feedback loop. Because of these constraints, for the time being we are likely pivoting toward a lightweight MCP-only approach rather than a deep "hooks" integration.

Your work has been very helpful in highlighting these platform nuances, and we may reference some of your approaches when we implement our own version. For future contributions, we highly recommend engaging with us on the Community Forum or (with your internal access to the team) via our issue tacker before investing significant time in large-scale features. This ensures alignment with our evolving architecture and avoids situations where your hard work might conflict with our internal roadmap. 🤝

Thank you again for your interest and for such a high-quality contribution to the discussion. More than happy to follow-up private message from here! 🤙