We've been evaluating Claw-Code's enterprise API for several weeks as part of a broader initiative to automate code review for our legacy monolithic application. The initial integration for incremental pull request analysis works acceptably. However, our mandated security and compliance framework requires a full-repository scan every 24 hours to surface any new issues introduced outside of the PR workflow.
This is where we encounter persistent failures. Every night, our orchestration job initiates a scan of the entire codebase (approximately 2.1 million lines of Java and TypeScript). The job submits the analysis request to the Claw-Code `/v1/full-scan` endpoint, polls for status, and consistently receives a 502 Bad Gateway error after 22-25 minutes of processing. The error payload is generic, stating only `{"error": "Gateway timeout"}`.
Our configuration and environment details are as follows:
- **API Client**: We are using the official `claw-code-client` Node.js library, version 2.3.1.
- **Request Parameters**: We set `scan_depth` to `"deep"`, `timeout` to 1800000 (30 minutes), and include our standard rule bundles for security, performance, and deprecated patterns.
- **Infrastructure**: Our job runs in a Kubernetes pod with ample resources (4 CPU, 16Gi memory). Network egress from our VPC to Claw-Code's published API endpoints is unrestricted.
- **Retry Logic**: We have implemented an exponential backoff retry (3 attempts), but the error is deterministic on the full-repo scan. Incremental/diff scans on the same codebase complete without issue.
I have reviewed the Claw-Code documentation and it mentions that 502 errors can originate from their upstream processing layer, but troubleshooting guidance is sparse. My primary hypotheses are:
1. Our payload, due to the repository size, is triggering an undocumented processing timeout on their side, despite our client-side setting.
2. There is a silent failure in their analysis of certain file types or complex inheritance structures that only manifests in long-running scans.
3. We may need to implement a different strategy, such as partitioning the scan by module and using the batch API, but this compromises the holistic analysis we require.
Has anyone else implemented nightly full-repository scans with Claw-Code at a similar scale? Were you able to resolve 502 errors by adjusting request parameters, or did you require a support ticket and a configuration change on the Claw-Code side? Specifically, I am seeking:
- Any non-obvious request headers or parameters that improve reliability for large scans.
- The actual timeout limits for the `/v1/full-scan` endpoint, as they are not documented.
- Whether breaking the scan into sequential modules proved effective, and if so, how you managed cross-module dependency analysis.
Our next step is to engage their support, but I wanted to consult the community for practical workarounds or validation of our approach first. The success of this pilot is critical for our broader platform consolidation strategy.
Migrate slow, validate fast.