Known Issues & Future Work

All fixable issues from the original report have been resolved. The remaining items require either architectural changes, new features, or deep investigation of the Go language server binary.

🔴 Blockers (Require Deep Investigation)

1. LS Go LLM Client Ignores System TLS Trust Store

File: docs/mitm-interception-status.md

The LS binary's Go HTTP client for LLM API calls uses a custom tls.Config that does not trust system CAs or honor SSL_CERT_FILE. Our MITM proxy can route traffic but not decrypt it.

Investigation status: All practical approaches have been tried and failed:

iptables REDIRECT → redirect loop + broke all HTTPS traffic
DNS redirect → same TLS trust failure
LD_PRELOAD → Go doesn't use libc for syscalls
SSLKEYLOGFILE → Go doesn't support it

Remaining options (untried):

Binary patching Go TLS verification (fragile, breaks on updates)
Full standalone LS control (see issue #2)
eBPF/ptrace syscall interception (complex)
Network namespace isolation (complex setup)

Confidence: <30% — all easy paths exhausted. Requires reverse engineering the Go binary's TLS setup.

See: docs/mitm-interception-status.md for full analysis

2. Standalone LS Cascades Silently Fail

File: docs/standalone-ls-todo.md

Standalone LS (outside Antigravity) accepts StartCascade RPCs without error but cascade never progresses. No output.

Suspected blockers:

Missing auth context (OAuth token propagation)
Different Unleash feature flags between main and standalone instances
Missing initialization steps (LoadCodeAssist, OnboardUser)
Missing extension server callbacks (WriteCascadeEdit, ExecuteCommand)

Confidence: <30% — too many unknowns. Needs systematic debugging with the standalone LS.

See: docs/standalone-ls-todo.md for investigation plan

Medium (Architecture / Future Work)

3. Cascade Correlation Is Heuristic

File: src/mitm/intercept.rs — extract_cascade_hint()

The MITM proxy matches intercepted API traffic to cascade IDs heuristically:

HTTP/1.1 path: scans JSON body for metadata.user_id or workspace_id
gRPC/H2 path: recursively searches proto fields for UUID strings

If neither method finds a match, usage is stored under _latest but never consumed (since take_usage() requires exact cascade ID match).

Confidence: <50% — can't test without working MITM interception (blocked by issue #1). The heuristic is reasonable but unverified against real traffic.

4. Request Modification Not Implemented

File: src/mitm/proxy.rs — modify_requests: bool

The MitmConfig.modify_requests flag is plumbed through the entire call chain but hardcoded to false. No modification logic exists. This is intentional scaffolding for future use.

Status: Not a bug — reserved for potential request mutation features.

5. Polling-Based Cascade Updates vs Streaming RPC

File: src/api/polling.rs

We poll GetCascadeTrajectorySteps on a timer. The LS has a StreamCascadeReactiveUpdates streaming gRPC method that pushes updates in real-time. Polling works but adds latency.

Status: Functional but suboptimal. Switching to streaming requires implementing a gRPC streaming client with reconnection handling. Not blocking.

🟢 Low

6. No Integration Tests for MITM Module

Unit tests cover protobuf decoding and intercept parsing (17 tests pass), but no integration tests for:

TLS interception end-to-end with the generated CA
Full HTTP/1.1 request/response cycle through the proxy
gRPC (HTTP/2) request/response cycle through h2_handler
Store recording and retrieval under concurrency

Status: The MITM can't intercept real traffic anyway (blocked by issue #1), so integration tests would be somewhat hypothetical. Worth adding when the TLS blocker is resolved.

3.9 KiB Raw Blame History