OpenCodeReview Version
v1.11.2 (and all versions since v1.10.0 / PR #1051)
Operating System
Linux (x86_64)
Installation Method
GitHub Action (composite action action.yml)
LLM Provider
OpenAI (openai-responses / Responses API)
Bug Description
In action.yml, the Configure OCR step added in PR #1051 unconditionally overwrites llm.protocol with "openai" whenever llm_use_anthropic is not set to true:
NORMALIZED_USE_ANTHROPIC="$(printf '%s' "$OCR_USE_ANTHROPIC" | tr '[:upper:]' '[:lower:]')"
case "$NORMALIZED_USE_ANTHROPIC" in
""|true|1|yes)
OCR_USE_ANTHROPIC="true"
OCR_LLM_PROTOCOL="anthropic"
;;
*)
OCR_USE_ANTHROPIC="false"
OCR_LLM_PROTOCOL="openai"
;;
esac
ocr config unset provider
...
ocr config set llm.protocol "$OCR_LLM_PROTOCOL"
This causes two major issues:
- It unsets any configured provider and ignores
OCR_LLM_PROTOCOL passed via workflow step env: (e.g. OCR_LLM_PROTOCOL: openai-responses).
- When calling OpenAI with the Responses API format (e.g.
llm_extra_body: '{"reasoning":{"effort":"medium"}}' or when using reasoning models with function tools), all requests are forced to /v1/chat/completions instead of /v1/responses, resulting in 400 Bad Request from OpenAI API (Unknown parameter: 'reasoning' or Function tools with reasoning_effort are not supported for model in /v1/chat/completions).
Prior to PR #1051 (e.g. in v1.9.10), Configure OCR did not touch llm.protocol or unset the provider, allowing OCR_LLM_PROTOCOL: openai-responses to be passed via environment variables directly to the CLI.
Steps to Reproduce
- In a GitHub Actions workflow, invoke
alibaba/open-code-review with llm_url: https://api.openai.com/v1, llm_use_anthropic: "false", env: OCR_LLM_PROTOCOL: openai-responses, and llm_extra_body: '{"reasoning":{"effort":"medium"}}'.
- Inspect the step log:
Configure OCR executes ocr config set llm.protocol openai.
- In
ocr review, all API calls fail with POST "https://api.openai.com/v1/chat/completions": 400 Bad Request {"message": "Unknown parameter: 'reasoning'."}.
Expected Behavior
action.yml should allow using the openai-responses protocol (and any custom protocol) either by:
- Preserving
OCR_LLM_PROTOCOL when set in the environment:
if [ -z "$OCR_LLM_PROTOCOL" ]; then
case "$NORMALIZED_USE_ANTHROPIC" in
""|true|1|yes) OCR_LLM_PROTOCOL="anthropic" ;;
*) OCR_LLM_PROTOCOL="openai" ;;
esac
fi
- Or exposing a dedicated
llm_protocol input in action.yml.
Logs / Error Output
POST "https://api.openai.com/v1/chat/completions": 400 Bad Request {
"message": "Unknown parameter: 'reasoning'.",
"type": "invalid_request_error",
"param": "reasoning",
"code": "unknown_parameter"
}
OpenCodeReview Version
v1.11.2 (and all versions since v1.10.0 / PR #1051)
Operating System
Linux (x86_64)
Installation Method
GitHub Action (composite action
action.yml)LLM Provider
OpenAI (
openai-responses/ Responses API)Bug Description
In
action.yml, theConfigure OCRstep added in PR #1051 unconditionally overwritesllm.protocolwith"openai"wheneverllm_use_anthropicis not set to true:This causes two major issues:
OCR_LLM_PROTOCOLpassed via workflow stepenv:(e.g.OCR_LLM_PROTOCOL: openai-responses).llm_extra_body: '{"reasoning":{"effort":"medium"}}'or when using reasoning models with function tools), all requests are forced to/v1/chat/completionsinstead of/v1/responses, resulting in400 Bad Requestfrom OpenAI API (Unknown parameter: 'reasoning'orFunction tools with reasoning_effort are not supported for model in /v1/chat/completions).Prior to PR #1051 (e.g. in
v1.9.10),Configure OCRdid not touchllm.protocolor unset the provider, allowingOCR_LLM_PROTOCOL: openai-responsesto be passed via environment variables directly to the CLI.Steps to Reproduce
alibaba/open-code-reviewwithllm_url: https://api.openai.com/v1,llm_use_anthropic: "false",env: OCR_LLM_PROTOCOL: openai-responses, andllm_extra_body: '{"reasoning":{"effort":"medium"}}'.Configure OCRexecutesocr config set llm.protocol openai.ocr review, all API calls fail withPOST "https://api.openai.com/v1/chat/completions": 400 Bad Request {"message": "Unknown parameter: 'reasoning'."}.Expected Behavior
action.ymlshould allow using theopenai-responsesprotocol (and any custom protocol) either by:OCR_LLM_PROTOCOLwhen set in the environment:llm_protocolinput inaction.yml.Logs / Error Output