PI agent支持

[hiant]

是否能够在文档中补充下 pi-coding-agent 的配置说明？尝试了用 /v1 不带 /v1 都是报的403，也没找到是哪里的返回。当前docker启动时，是否有像nginx那样，记录所有的请求呢？包括403、500、200等

[github-actions]

Thank you for your question.

PI Agent (pi-coding-agent) Compatibility

Based on my analysis of the codebase, there is currently no specific support or documentation for pi-coding-agent in claude-code-hub. The system is designed primarily for the following clients:

• Claude Code (VSCode Extension / CLI)
• OpenAI-compatible clients (via /v1/chat/completions)
• Codex CLI (via /v1/responses)
• Gemini CLI (via /v1beta/models/... and /v1internal/models/...)

That said, pi-coding-agent should be able to work if it uses a standard API format (Claude Messages API or OpenAI Chat Completions).

---

Diagnosing the 403 Error

Looking at the codebase, the proxy guards (src/app/v1/_lib/proxy/guard-pipeline.ts:172-188) do not directly return 403 errors. The auth guard (src/app/v1/_lib/proxy/auth-guard.ts) returns 401 for authentication failures. A 403 would typically come from the upstream provider being forwarded back through the proxy.

Common causes for your error:

1. Authentication issue (401, may appear as 403 depending on client interpretation):

   • No API key provided, or key provided in wrong header format
   • Invalid/disabled/expired API key
   • The proxy accepts keys via: Authorization: Bearer <key>, x-api-key: <key>, or x-goog-api-key: <key> (src/app/v1/_lib/proxy/auth-guard.ts:10-14)

2. Client restriction (400):

   • If the admin configured allowedClients for your user, and pi-coding-agent's User-Agent doesn't match any allowed pattern (src/app/v1/_lib/proxy/client-guard.ts:28-55)

3. Upstream provider returning 403:

   • The upstream API key configured in the provider may be invalid or lack permissions

To configure pi-coding-agent, you would need to point it at:

• /v1/messages if it uses the Claude Messages API format
• /v1/chat/completions if it uses the OpenAI-compatible format

And provide your claude-code-hub API key in the Authorization: Bearer <key> or x-api-key header.

---

Request Logging

The application does not have nginx-style access logs by default, but it does have two logging mechanisms:

1. Application logs (stdout/stderr): Uses Pino logger (src/lib/logger.ts). You can increase verbosity by setting the LOG_LEVEL environment variable to debug or trace in your Docker environment. The default in production is info. You can also set DEBUG_MODE=true for debug-level logging.

2. Database request log: Every proxied request is recorded in the message_request table (src/drizzle/schema.ts:381-468), which includes status_code (line 403), endpoint (line 409), user_agent (line 440), error_message, and more. You can view these in the dashboard.

To see detailed logs from Docker:

# View container logs with debug level
docker logs <container_name>

# Or set LOG_LEVEL=debug in your docker-compose environment variables

Note that failed authentication requests (401) are logged at debug level in the auth guard, so you will need LOG_LEVEL=debug to see them in the container output.

---

Summary: pi-coding-agent is not explicitly supported yet, but it should work if configured to use a standard API format. Setting LOG_LEVEL=debug in your Docker environment will help you see exactly where the request is failing in the guard pipeline.

---

Automated response from Claude AI

[ding113]

您好，请提供详细的报错和日志以供排查。
目前暂无精力撰写更多接入文档，但是欢迎在解决后提交 PR。