Describe the bug
First, thank you for creating this plugin. I'm a big fan of opencode so being able to use Kiro without needing to manage my own custom provider is so nice to have.
I'm using a -thinking model with a variant selected (via OMO, which sets the native OpenCode variant agent-config field — e.g. model: kiro/claude-sonnet-5-thinking, variant: "max"), which resolves a non-empty effort value in the plugin and triggers the buggy code path. Every such request logs:
@aws-sdk/core/protocols - WARN - JsonCodec2: you have called a string method on a Uint8Array request body. It has been automatically converted to string. In a future version this will throw an error.
Root cause: in src/plugin/sdk-client.ts, the addEffortConfig middleware does JSON.parse(args.request.body) assuming args.request.body is a plain string. With the currently-resolved @aws-sdk/core (3.977.6), the serializer produces a JsonBytesStringAdapter — a Uint8Array subclass whose toString()/valueOf() lazily decode to UTF-8 and log the deprecation warning on first use. JSON.parse() on a non-string argument implicitly calls .toString(), hitting that path.
It currently still works — decode succeeds, JSON.parse succeeds, request goes out fine — but AWS's own comment states a future SDK version will throw instead of auto-converting, so this will break outright once that lands.
To Reproduce
- Install
@zhafron/opencode-kiro-auth (v2.0.0, or any version once @aws-sdk/core resolves to a JsonCodec2-era release transitively via @aws/codewhisperer-streaming-client).
- Configure a
-thinking model with a variant, e.g.:
{ "model": "kiro/claude-sonnet-5-thinking", "variant": "max" }
(any variant that makes getEffectiveEffort() resolve a defined effort works)
- Send a message using that model/variant in OpenCode.
- The
JsonCodec2 warning appears in the chat area, as shown in the attached screenshot.
Expected behavior
No deprecation warning. The effort-injection middleware should decode the request body correctly regardless of whether the SDK hands it a string or a byte-backed body, without relying on implicit toString() coercion.
Screenshots
Desktop (please complete the following information):
- OS: NixOS (Linux)
- OpenCode version: 1.18.13
- Plugin:
@zhafron/opencode-kiro-auth v2.0.0
@aws-sdk/core: 3.977.6 (resolved via @aws/codewhisperer-streaming-client 1.0.45, declared range ^3.974.7)
- Install method: opencode plugin manager,
@latest
Additional context
Verified fix locally by patching the installed dist/plugin/sdk-client.js:
if (args.request?.body) {
try {
const rawBody = args.request.body
const bodyStr = typeof rawBody === 'string' ? rawBody : new TextDecoder().decode(rawBody)
const body = JSON.parse(bodyStr)
body.additionalModelRequestFields = {
output_config: { effort }
}
args.request.body = JSON.stringify(body)
} catch {
// If body parsing fails, continue without modification
}
}
Warning no longer appeared with the same model/variant config that reproduced it. This was just a quick fix I had my agent do to continue work. By no means am I suggesting that this is the exact fix. I would prefer your expertise on that matter.
This report and the suggested fix were drafted with the help of Kiro, then reviewed by me.
Describe the bug
First, thank you for creating this plugin. I'm a big fan of opencode so being able to use Kiro without needing to manage my own custom provider is so nice to have.
I'm using a -thinking model with a variant selected (via OMO, which sets the native OpenCode variant agent-config field — e.g. model: kiro/claude-sonnet-5-thinking, variant: "max"), which resolves a non-empty effort value in the plugin and triggers the buggy code path. Every such request logs:
Root cause: in
src/plugin/sdk-client.ts, theaddEffortConfigmiddleware doesJSON.parse(args.request.body)assumingargs.request.bodyis a plain string. With the currently-resolved@aws-sdk/core(3.977.6), the serializer produces aJsonBytesStringAdapter— aUint8Arraysubclass whosetoString()/valueOf()lazily decode to UTF-8 and log the deprecation warning on first use.JSON.parse()on a non-string argument implicitly calls.toString(), hitting that path.It currently still works — decode succeeds,
JSON.parsesucceeds, request goes out fine — but AWS's own comment states a future SDK version will throw instead of auto-converting, so this will break outright once that lands.To Reproduce
@zhafron/opencode-kiro-auth(v2.0.0, or any version once@aws-sdk/coreresolves to a JsonCodec2-era release transitively via@aws/codewhisperer-streaming-client).-thinkingmodel with a variant, e.g.:{ "model": "kiro/claude-sonnet-5-thinking", "variant": "max" }getEffectiveEffort()resolve a defined effort works)JsonCodec2warning appears in the chat area, as shown in the attached screenshot.Expected behavior
No deprecation warning. The effort-injection middleware should decode the request body correctly regardless of whether the SDK hands it a string or a byte-backed body, without relying on implicit
toString()coercion.Screenshots
Desktop (please complete the following information):
@zhafron/opencode-kiro-authv2.0.0@aws-sdk/core: 3.977.6 (resolved via@aws/codewhisperer-streaming-client1.0.45, declared range^3.974.7)@latestAdditional context
Verified fix locally by patching the installed
dist/plugin/sdk-client.js:Warning no longer appeared with the same model/variant config that reproduced it. This was just a quick fix I had my agent do to continue work. By no means am I suggesting that this is the exact fix. I would prefer your expertise on that matter.
This report and the suggested fix were drafted with the help of Kiro, then reviewed by me.