Published `--json` CLI crashes with misleading "Error: database error:" prefix and exit code 3 on trimmed build

[Widthdom]

Context

On the published v1.9.0 binary (built with PublishTrimmed=true), any CLI command invoked with --json crashes because reflection-based System.Text.Json serialization is disabled under trimming. CLOUD_BOOTSTRAP_PROMPT.md acknowledges this as a known caveat. The end-user visible shape of the crash is what this issue is about.

Repro

curl -fsSL https://raw.githubusercontent.com/Widthdom/CodeIndex/main/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"

cdidx . --db /tmp/smoke.db
cdidx status --db /tmp/smoke.db --json
echo "exit=$?"

Observed

Error: database error: Reflection-based serialization has been disabled for this application. Either use the source generator APIs or explicitly configure the 'JsonSerializerOptions.TypeInfoResolver' property.
exit=3

Also reproduces with cdidx <projectPath> --json, cdidx search "..." --json, cdidx files --json, etc.

Why this is worse than just "--json is broken"

The surface behavior looks like a database problem to anyone who does not already know about the trimming caveat:

1. The error is classified as database error: — the underlying InvalidOperationException from System.Text.Json is caught somewhere that assumes a SQLite/IO failure, and prepends a "database error:" label to a message that has nothing to do with the database.
2. The exit code is 3 (database error) per CommandExitCodes.DbError, not a separate "internal"/"unsupported" code, so AI clients and CI scripts that branch on exit codes treat this as a legitimate DB failure and e.g. trigger reindex recovery paths.
3. The caveat is only mentioned in CLOUD_BOOTSTRAP_PROMPT.md, which most end users never see. The README advertises --json extensively (AI-first positioning), and there is no user-visible hint that it is currently non-functional on the published release.

Why this matters

• --json is the documented AI/automation contract for CLI consumers (the non-MCP path). On the release users actually install via the one-liner, that entire contract is down. MCP is unaffected because it hand-rolls JSON.
• The "database error" prefix sends the first-time debugger the wrong direction (rebuild the DB, inspect schema, etc.) instead of toward the real root cause (trimming + reflection-based serialization).
• Exit code 3 overloads the "DB is broken; run --rebuild" signal onto a case where the DB is fine.

Suggested directions

1. Fix the root cause: wire a source-generator JsonSerializerContext (JsonSerializable(typeof(...))) for the DTOs emitted by CLI JSON paths, or set JsonSerializerOptions.TypeInfoResolver = new DefaultJsonTypeInfoResolver() where safe, or disable PublishTrimmed in the release build. This is the only real fix.
2. In the meantime, improve the observable failure:
   • Detect the InvalidOperationException: Reflection-based serialization has been disabled message at the CLI JSON boundary and emit a dedicated error — e.g. Error: --json is not available on this build (trimmed release). Use MCP for structured output, or default human-readable output otherwise.
   • Use a distinct exit code (not 3/DbError) — this is neither a usage error (1), not-found (2), nor a database error (3); a new "build limitation" / "feature unavailable" code would match the existing structured exit-code design better.
   • Note the limitation in README.md under the --json documentation so users do not discover it by crash.

Scope

• Either a real serialization fix, or a small error-mapping + doc fix. Both are additive.
• No change to MCP (already works).

Environment

• cdidx: v1.9.0 (installed via install.sh one-liner)
• Platform: linux-x64 container
• Filed during a cloud Claude Code session per CLOUD_BOOTSTRAP_PROMPT.md.

Notes

Searched open/closed issues for "trimmed"/"PublishTrimmed"/"reflection-based serialization"/"database error" misclassification — no existing match. The known-caveat note is in CLOUD_BOOTSTRAP_PROMPT.md only.

[Widthdom]

Follow-up: state of main as of 6632157

Cross-checked whether this was already addressed before filing stuck around. Summary: still unaddressed on main.

Release build is still trimmed

.github/workflows/release.yml on main still publishes with:

dotnet publish src/CodeIndex/CodeIndex.csproj
  --configuration Release
  --runtime ${{ matrix.rid }}
  --self-contained true
  -p:PublishSingleFile=true
  -p:PublishTrimmed=true

No change to the trimming flag, no JsonSerializerContext added, no TypeInfoResolver override wired in. src/CodeIndex/CodeIndex.csproj on main is unchanged in this respect (only Microsoft.Data.Sqlite dependency, no AOT / source-gen JSON configuration).

No related issue / PR

Searched open and closed issues for trimmed, PublishTrimmed, JsonSerializerContext, TypeInfoResolver, reflection-based serialization, and "database error" misclassification — zero matches in either state. No open PR currently touches the trim/JSON gap or the error-classification prefix.

Commit scan since v1.9.0

Reviewed the PRs merged after v1.9.0 on main (#140, #141, #142, #143, #144, #145, #148). None of them:

• switch the CLI --json path to a source-generated serializer
• drop PublishTrimmed=true
• add a dedicated error-mapping for the reflection-disabled exception
• introduce a separate exit code for "feature unavailable on this build"
• add a README note that --json is currently non-functional on the published release

Net

Both halves of the issue remain live on 6632157:

1. The crash still occurs on the published binary (root cause unfixed).
2. The observable failure is still labeled Error: database error: with exit code 3 (misclassification unfixed).

If the root-cause fix is non-trivial to land quickly, the smaller mitigation — mapping the reflection-disabled exception at the CLI JSON boundary so the prefix/exit code stop looking like a DB failure — is self-contained and could ship independently ahead of the full source-gen migration.

---

Generated by Claude Code

[Widthdom]

Update: MCP is NOT unaffected — the trimming bug breaks every tool call, not just CLI --json

While dogfooding cdidx against /opt/pw-browsers/chromium-1194/chrome-linux/resources/inspector_overlay/main.js I tried the same query via MCP, and found that the current reading in CLOUD_BOOTSTRAP_PROMPT.md —

MCP output is unaffected because the MCP path hand-rolls JSON.

— is factually incorrect on the published v1.9.0 binary. Only initialize escapes; every tools/call I tested fails with the same reflection-disabled exception.

Repro

curl -fsSL https://raw.githubusercontent.com/Widthdom/CodeIndex/main/install.sh | bash
CDIDX=/root/.local/bin/cdidx

"$CDIDX" /opt/pw-browsers/chromium-1194/chrome-linux/resources --db /tmp/minified.db

for tool in search symbols definition references callers callees files status map; do
  echo "=== $tool ==="
  printf '%s\n' \
    '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
    "{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\"params\":{\"name\":\"$tool\",\"arguments\":{\"query\":\"canvas\",\"limit\":1}}}" \
    | "$CDIDX" mcp --db /tmp/minified.db 2>/dev/null \
    | tail -1 | head -c 200
  echo
done

Observed

All nine tools return an isError: true JSON-RPC response whose content[0].text starts with:

Error executing <tool>: Reflection-based serialization has been disabled for this application.
Either use the source generator APIs or explicitly configure the 'JsonSerializerOptions.TypeInfoResolver' property.

initialize still returns the serverInfo + instructions block fine, so the connection negotiation is intact — but every actual data query fails identically.

Why this changes priority

• The original issue framed this as "CLI --json is broken". It is actually "CLI --json AND MCP tool execution are both broken on the published binary".
• MCP is cdidx's stated AI-first interface per README and the MCP instructions string. Telling AI clients "use MCP for structured responses, --json is broken" (the workaround CLOUD_BOOTSTRAP_PROMPT.md recommends) doesn't actually work — the clients hit the same exception one layer deeper.
• The only path that currently works on a fresh install is the human-readable CLI output. That's not an AI-friendly fallback.

Suggested doc update regardless of fix

CLOUD_BOOTSTRAP_PROMPT.md Step 2 + "Known caveat" section both need correcting so cloud-session AIs don't waste retries chasing an MCP workaround that doesn't exist on v1.9.0. The note should read something like "both --json CLI and MCP tool responses crash on the trimmed release; use default human-readable CLI output until a patch release ships." Doc-only fix is cheap and immediate.

The real fix (source-gen JsonSerializerContext or dropping PublishTrimmed) remains the right endgame, and is unchanged by this comment.

Environment

• cdidx: v1.9.0 (installed via install.sh)
• Platform: linux-x64 container
• Filed from a cloud Claude Code session per CLOUD_BOOTSTRAP_PROMPT.md.

---

Generated by Claude Code