Summary
codedb_remote is advertised as the official path for querying indexed public GitHub repositories via api.wiki.codes, but it currently returns HTTP 530 / error code 1033 for multiple public repositories, including the codedb repository itself.
I am a paid CodeGraff Pro user relying on CodeGraff/codedb as the primary Codex navigation path. This failure makes official-repo inspection unreliable and forces agents to fall back to other web/GitHub tools.
Environment
codedb --version: codedb 0.2.5820- CodeGraff Pro:
muonry status reports Codegraff Pro — license valid
- Client surface: Codex Desktop MCP
mcp__codedb__codedb_remote
- Date observed: 2026-05-28
Reproduction
Run either of these remote reads:
codedb_remote repo="justrach/codedb" action="read" path="README.md" lines="1-20"
codedb_remote repo="openai/codex" action="read" path="README.md" lines="1-20"
Observed output for justrach/codedb:
✗ • remote — api.wiki.codes HTTP 530 for justrach-codedb/read — error code: 1033
error: api.wiki.codes HTTP 530 for justrach-codedb/read — error code: 1033
Observed output for openai/codex:
✗ • remote — api.wiki.codes HTTP 530 for openai-codex/read — error code: 1033
error: api.wiki.codes HTTP 530 for openai-codex/read — error code: 1033
The same pattern was also observed against other public repos during the same session, including Yeachan-Heo/oh-my-codex and openclaw/openclaw.
Expected behavior
For indexed public repos, codedb_remote should return the requested content or a clear non-530 explanation such as repo not indexed, path not indexed, rate limited, or service unavailable with retry-after.
Actual behavior
The tool returns HTTP 530 / code 1033. There is no actionable remediation, retry guidance, or service-status indication.
Impact
This blocks the documented CodeGraff-first workflow for official upstream repo inspection. It also makes it hard to distinguish a repo/content issue from an infrastructure outage.
Requested resolution
Please provide an official fix, public status explanation, or supported fallback guidance for codedb_remote. If the remote public-repo feature cannot be made reliable for paid users, please clarify whether this is covered by the CodeGraff refund policy.
Summary
codedb_remoteis advertised as the official path for querying indexed public GitHub repositories viaapi.wiki.codes, but it currently returns HTTP 530 / error code 1033 for multiple public repositories, including thecodedbrepository itself.I am a paid CodeGraff Pro user relying on CodeGraff/codedb as the primary Codex navigation path. This failure makes official-repo inspection unreliable and forces agents to fall back to other web/GitHub tools.
Environment
codedb --version:codedb 0.2.5820muonry statusreportsCodegraff Pro — license validmcp__codedb__codedb_remoteReproduction
Run either of these remote reads:
Observed output for
justrach/codedb:Observed output for
openai/codex:The same pattern was also observed against other public repos during the same session, including
Yeachan-Heo/oh-my-codexandopenclaw/openclaw.Expected behavior
For indexed public repos,
codedb_remoteshould return the requested content or a clear non-530 explanation such asrepo not indexed,path not indexed,rate limited, orservice unavailable with retry-after.Actual behavior
The tool returns HTTP 530 / code 1033. There is no actionable remediation, retry guidance, or service-status indication.
Impact
This blocks the documented CodeGraff-first workflow for official upstream repo inspection. It also makes it hard to distinguish a repo/content issue from an infrastructure outage.
Requested resolution
Please provide an official fix, public status explanation, or supported fallback guidance for
codedb_remote. If the remote public-repo feature cannot be made reliable for paid users, please clarify whether this is covered by the CodeGraff refund policy.