codex-msg-translator

A CLIProxyAPI request-interceptor plugin that transpiles Codex multi-agent agent_message payloads (encrypted_content) into plaintext input_text, so DeepSeek and other OpenAI-compatible endpoints can receive spawn / followup / send_message tasks.

Problem

• Codex 0.149 multi-agent delegation (spawn_agent / followup_task / send_message) puts the task text in plaintext inside InterAgentCommunication.encrypted_content; when serialized for the model endpoint it becomes an {"type":"encrypted_content","encrypted_content":"<task text>"} block next to the input_text envelope (Message Type: ... Payload:\n).
• The official OpenAI Responses endpoint consumes that block natively, but DeepSeek and other openai-compat endpoints silently drop it — child agents only see an empty Payload:.
• CLIProxyAPI 7.2.141's native openai-response → openai conversion only understands input_text / input_image, so it drops encrypted_content too.

Mechanism

The plugin registers the request_interceptor capability and implements request.intercept_before. The host calls it at the handler layer, before any native format conversion, with the client's original responses request body (including the plaintext encrypted_content blocks). The plugin:

1. Parses the request body and walks the input[] items.
2. For each encrypted_content block with a value, appends the value (\n<value>) to the last input_text block of the same item whose text contains Message Type: or Payload:; if no matching input_text exists, the block is replaced with {"type":"input_text","text":"<value>"}.
3. Deletes the encrypted_content blocks and returns the rewritten body.

Only requests whose Model (or RequestedModel) contains deepseek are rewritten; all other traffic passes through untouched. request.translate is also implemented with the same rules as a fallback for hosts without a native route.

Configuration

Place codex-msg-translator.dll in the main program's plugin directory, e.g.:

<CLIProxyAPI app dir>\plugins\windows\amd64\codex-msg-translator.dll

Enable it in config.yaml:

plugins:
  enabled: true
  configs:
    codex-msg-translator:
      enabled: true
      priority: 10

Restart CLIProxyAPI (or hot-reload if your management panel supports it) after changing the config.

Build

Requires Go with CGO. On Windows with mingw:

CGO_ENABLED=1 go build -buildmode=c-shared -o codex-msg-translator.dll .

Or cross-compile from Linux:

GOOS=windows GOARCH=amd64 CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc go build -buildmode=c-shared -o codex-msg-translator.dll .

A one-command helper is provided (uses local mingw when available, otherwise Docker cross-compilation):

.\build.ps1          # builds the dll, packages the release zip and writes checksums.txt

Verification

1. The plugin is registered: management API shows registered=true and main.log contains plugin loaded / plugin registered with no invalid metadata / unsupported schema version.
2. Trigger a DeepSeek request (e.g. a Codex multi-agent task) and check the plugin log at %USERPROFILE%\.cli-proxy-api\logs\codex-msg-translator.log for:

request.intercept_before | model=deepseek-... modified=true encrypted=N input_items=X->Y body_len=A->B ...

modified=false reason=no_encrypted for ordinary requests is expected and healthy.

Known limitations & rollback

• The plugin only rewrites requests whose model hits the deepseek domain; other models keep the original encrypted_content path.
• Only the outbound request is rewritten; response-side behavior is untouched.
• Log lines record the first 80 chars of encrypted payload content (task text may contain sensitive information).
• To disable: set configs.codex-msg-translator.enabled: false (or delete the dll) and restart. The host fuses failing plugins and passes traffic through untouched, so an unhealthy plugin cannot break production.

License

MIT