Gitlawb/openclaude

This is fixed on `main`. The shim now sends `max_completion_tokens` (not `max_tokens`), and gpt-4o is capped at 16,384 in the output token table (`openaiContextWindows.ts`). If you rebuild from latest main, this error should be resolved.

fixed, thanks

This was fixed by PR #61 (commit \`6c35f4e\`), already merged into \`main\`.

Root cause: \`SandboxViolationExpandedView.tsx\` called \`.subscribe()\` on a null sandbox violation store. The store is null when sandboxing is not enabled (Linux, WSL2, or no sandbox configured).

The fix adds two guards in the \`useEffect\`:
- Early return if sandboxing is disabled or platform is Linux
- Null check on the store before calling \`.subscribe()\`

If you're still seeing this crash, try updating to the latest build.

This is already fixed on `main`. The full code path now correctly caps `max_completion_tokens` to 8192 for `deepseek-chat`:

1. `openaiContextWindows.ts:88` — `'deepseek-chat': 8_192` in OPENAI_MAX_OUTPUT_TOKENS
2. `context.ts:186-189` — `getModelMaxOutputTokens()` returns `{ default: 8192, upperLimit: 8192 }` for OpenAI providers
3. `openaiShim.ts:670-671` — sends `body.max_completion_tokens = 8192` (never `max_tokens`)

There are also two tests in `context.test.ts` verifying this behavior, including clamping of user overrides.

If you're still seeing this error, try rebuilding from latest `main`.

i create a pr https://github.com/Gitlawb/openclaude/pull/85

Thanks a lot for the fast reply and PR!

Using the discussed version

`export OPENAI_BASE_URL=https://................-eastus2.cognitiveservices.azure.com/openai/v1/
`
it now results in

```
API Error: OpenAI API error 400: {
"error": {
"message": "Unsupported parameter: 'max_tokens' is not
supported with this model. Use 'max_completion_tokens'
instead.",
"type": "invalid_request_error",
"param": "max_tokens",
"code": "unsupported_parameter"
}
}
```

I suppose that a change of parameter from 4.1 / 5 upwards.

P.S let an llm debug and fix the fix. For cli.mjs and openaiShim.ts. I can share details if needed.

async _doOpenAIRequest(request, params, options) {
const openaiMessages = convertMessages(params.messages, params.system);
const body = {
model: request.resolvedModel,
messag...

And with the Github Copilot CLI SDK, it could work if we rework claude

Fix submitted in PR #80.

The root cause was two Azure-specific requirements the shim wasn't handling:
1. Azure needs `api-key: {key}` header instead of `Authorization: Bearer {key}` → that's why you got 401 on the closest attempt
2. Azure needs `/openai/deployments/{model}/chat/completions?api-version={version}` path → that's why you got 404 on the others

After the fix, your setup with `/openai/v1` base URL should work directly:

```bash
export CLAUDE_CODE_USE_OPENAI=1
export OPENAI_API_KEY=your-azure-key
export OPENAI_BASE_URL=https://yourresource-eastus2.cognitiveservices.azure.com/openai/v1
export OPENAI_MODEL=gpt-5.4-nano
openclaude
```

If you need a specific api-version, you can also set `AZURE_OPENAI_API_VERSION` (defaults to `2024-12-01-preview`).

Thanks for confirming you're on `0.1.5`.

I’m able to use keyboard input on another Windows setup, so this doesn’t look like a universal Windows regression. It may be specific to a certain terminal, shell, or keyboard/layout setup.

Could you share a few more details so we can narrow it down?
- terminal app: Windows Terminal, PowerShell, CMD, VS Code terminal, etc.
- shell inside it: `cmd`, PowerShell, Git Bash, etc.
- keyboard layout / OS language
- whether the same issue happens in a different terminal app on the same machine

That should help tell whether this is a terminal-specific compatibility issue or a broader OpenClaude bug.

not in OpenClaude today, but technically possible.

Right now OpenClaude only supports providers that are already wired in:
- Anthropic
- OpenAI-compatible endpoints
- Gemini
- Bedrock / Vertex / Foundry
- Codex

GitHub Copilot is different because GitHub does not expose a stable/public third-party API for this use case the same way OpenAI or Gemini do.

That said, tools like Opencode / Continue make it work by using GitHub’s undocumented internal Copilot flow:
- get a short-lived token from GitHub
- use that token against `api.githubcopilot.com`

So:
- **supported in OpenClaude today:** no
- **possible to add:** yes, probably
- **official/public/stable API:** not really

That’s why the answer is a bit awkward: it’s not “impossible,” but it’s also not something OpenClaude currently supports out of the box.

If someone wants to add it, it would likely need a dedicated Copilot auth/provider integration rather than just setting `OPENAI_BASE_URL` and `OPENAI_MODEL`. @Harmonicrain

keyboard still not working

check on that terminal

Good catch @Harmonicrain — I was wrong to say it's completely impossible.

Opencode supports Copilot by using GitHub's **undocumented internal API** (`https://api.githubcopilot.com`). The flow is:
1. Exchange your GitHub OAuth token at `https://api.github.com/copilot_internal/v2/token` to get a short-lived Copilot token
2. Use that token against the `api.githubcopilot.com` endpoint, which is OpenAI-compatible

It's not an official/public API — GitHub hasn't documented it — but tools like Opencode and Continue.dev have reverse-engineered it and it works.

OpenClaude could support this too by implementing the same token exchange flow. If anyone wants to contribute that, it would be a great addition — the endpoint is OpenAI-compatible so it would slot in alongside the existing OpenAI shim.

This looks very similar to the earlier Windows keyboard/input issue that was fixed recently.

Could you first check which version you’re running?

```bash
openclaude --version
The current npm version is 0.1.5, so if you’re on an older version, please update first:

npm install -g @gitlawb/openclaude@latest
If it still happens on 0.1.5, please share:

your OS
terminal app (Windows Terminal, PowerShell, CMD, Git Bash, VS Code terminal, etc.)
the output of openclaude --version
That’ll help tell whether this is the old fixed issue or a new terminal-specific one.