![[Small Update] Node.js Runtime is now available to select in Amazon Bedrock AgentCore Code Interpreter](https://images.ctfassets.net/ct0aopd36mqt/7M0d5bjsd0K4Et30cVFvB6/5b2095750cc8bf73f04f63ed0d4b3546/AgentCore2.png?w=3840&fm=webp)
[Small Update] Node.js Runtime is now available to select in Amazon Bedrock AgentCore Code Interpreter
This page has been translated by machine translation. View original
Introduction
Hello, this is Kamino from the Consulting Department, who also loves ramen.
Amazon Bedrock AgentCore's Code Interpreter can execute JavaScript/TypeScript, but until now I hadn't paid much attention to which runtime it was using. Now, with the addition of runtime to the arguments of the InvokeCodeInterpreter API, we can explicitly specify Node.js.
I wonder if the execution environment has been Deno all along? Let's try it out!
Prerequisites
- AWS account
- Python 3.12 or higher (confirmed with 3.13.11)
- boto3 1.42.78 or higher (version supporting the
runtimeparameter) - Region where Bedrock AgentCore Code Interpreter is available (we'll use
us-east-1)
What Has Changed?
The official documentation states that ToolArguments' runtime parameter can be set to nodejs | deno | python, and when unspecified, JavaScript/TypeScript will use deno by default.
Additionally, the runtime selection page states that with the nodejs runtime, JavaScript supports CommonJS while TypeScript supports ESM. Let's verify if this is actually the case.
Testing It Out
Creating a Session
First, let's create a session. All subsequent code snippets will be executed in the same session.
import boto3
client = boto3.client("bedrock-agentcore", region_name="us-east-1")
session_response = client.start_code_interpreter_session(
codeInterpreterIdentifier="aws.codeinterpreter.v1",
name="nodejs-runtime-test",
sessionTimeoutSeconds=900,
)
session_id = session_response["sessionId"]
print(f"Session ID: {session_id}")
Let's also prepare a small helper function to make the execution results easier to read.
def execute_and_print(code: str, language="javascript", runtime=None):
arguments = {
"language": language,
"code": code,
}
if runtime:
arguments["runtime"] = runtime
response = client.invoke_code_interpreter(
codeInterpreterIdentifier="aws.codeinterpreter.v1",
sessionId=session_id,
name="executeCode",
arguments=arguments,
)
for event in response["stream"]:
if "result" not in event:
continue
result = event["result"]
if "structuredContent" not in result:
continue
stdout = result["structuredContent"].get("stdout", "")
stderr = result["structuredContent"].get("stderr", "")
if stdout:
print(stdout)
if stderr:
print(stderr)
Checking if Omitting runtime Still Uses Deno
First, let's run JavaScript without specifying runtime. We'll check for both Deno and process to see which runtime is being used.
execute_and_print("console.log(typeof Deno); console.log(typeof process);")
object
object
The Deno global object is visible, so when unspecified, it's still running on Deno as before! process also exists, but that's due to Deno's Node.js compatibility layer.
Does runtime: "nodejs" Switch to Node.js?
Next, let's run the same code with runtime: "nodejs".
execute_and_print(
"console.log(typeof Deno); console.log(typeof process);",
runtime="nodejs",
)
undefined
object
This time Deno is undefined. When we pass runtime: "nodejs", it properly switches to the Node.js runtime!
Checking the Node.js Version
Let's also check which version of Node.js is being used.
execute_and_print("console.log(process.version);", runtime="nodejs")
v24.14.0
As of April 5, 2026, it's using Node.js v24.14.0.
Using Built-in Modules with Node.js
Let's try loading built-in modules and doing some simple file operations with the Node.js runtime.
execute_and_print(
"""
const fs = require("fs");
const os = require("os");
console.log("Platform:", os.platform());
console.log("Architecture:", os.arch());
console.log("Node.js Path:", process.execPath);
console.log("CWD:", process.cwd());
console.log("Temp Dir:", os.tmpdir());
fs.writeFileSync("/tmp/test.txt", "Hello from Node.js runtime!");
const content = fs.readFileSync("/tmp/test.txt", "utf-8");
console.log("File content:", content);
""",
runtime="nodejs",
)
Platform: linux
Architecture: arm64
Node.js Path: /opt/amazon/genesis1p-tools/nodejs/bin/node
CWD: /opt/amazon/genesis1p-tools/var/nodejs-js-execution
Temp Dir: /tmp
File content: Hello from Node.js runtime!
At least the built-in modules' require() and file operations in /tmp work without issues.
Checking if require() Fails in Deno but Works in Node.js
While require() might not be used that often these days, it's a clear differentiator between runtimes, so let's check.
require_test_code = """
try {
const os = require("os");
console.log("Platform:", os.platform());
} catch (e) {
console.log("Error:", e.message);
}
"""
execute_and_print(require_test_code)
Error: require is not defined
execute_and_print(require_test_code, runtime="nodejs")
Platform: linux
If you want to bring in existing JavaScript that uses require(), using runtime: "nodejs" seems to be the way to go.
How Does JavaScript import Work?
Next, let's try the ESM import statement. First with JavaScript.
esm_code = """
import { join } from "node:path";
import { platform } from "node:os";
console.log("Platform:", platform());
console.log("Joined:", join("/tmp", "test", "file.txt"));
"""
execute_and_print(esm_code)
Platform: linux
Joined: /tmp/test/file.txt
execute_and_print(esm_code, runtime="nodejs")
SyntaxError: Cannot use import statement outside a module
With JavaScript, it works fine in Deno but fails in the Node.js runtime. As the official documentation states, it seems we should expect JavaScript in the Node.js runtime to use CommonJS.
For the nodejs runtime, we support CommonJS (CJS) modules for JavaScript and ECMAScript (ESM) modules for TypeScript.
How Does TypeScript import Work?
Let's try the same thing with TypeScript.
ts_code = """
import { join } from "node:path";
const result: string = join("/tmp", "hello.ts");
console.log("TypeScript result:", result);
console.log("Type check passed!");
"""
execute_and_print(ts_code, language="typescript")
TypeScript result: /tmp/hello.ts
Type check passed!
execute_and_print(ts_code, language="typescript", runtime="nodejs")
TypeScript result: /tmp/hello.ts
Type check passed!
With TypeScript, import works in both Deno and Node.js. This also matches what the official documentation says!
Additional Notes
It's worth noting that while Node.js itself supports ESM, the Code Interpreter's Node.js runtime executes JavaScript in CommonJS mode, so import is not available. Similarly, while Deno 2.x has compatibility support for require(), it's not available in the Code Interpreter. These are behaviors specific to the Code Interpreter.
In practice, since writing in TypeScript has become more mainstream recently, the fact that TypeScript can use import in both Deno and Node.js may be more important for practical use.
Using Node.js Runtime from Strands Agents
Now that we've confirmed the behavior using boto3 directly, let's check how to use it from Strands Agents. In strands-agents-tools version 0.4.1, the AgentCoreCodeInterpreter looks like this:
params = {
"code": action.code,
"language": action.language.value,
"clearContext": action.clear_context,
}
This implementation doesn't pass runtime, so we can't explicitly specify the Node.js runtime via the built-in tool. As of April 5, 2026, if you want to use the Node.js runtime, you might need to create a custom tool using code_session.
import json
from strands import Agent, tool
from bedrock_agentcore.tools.code_interpreter_client import code_session
@tool
def execute_nodejs(code: str) -> str:
"""Execute JavaScript code with Node.js runtime."""
with code_session("us-east-1") as code_client:
response = code_client.invoke(
"executeCode",
{
"code": code,
"language": "javascript",
"runtime": "nodejs",
},
)
for event in response["stream"]:
if "result" in event:
return json.dumps(event["result"])
return ""
agent = Agent(
tools=[execute_nodejs],
system_prompt="Use execute_nodejs when you need Node.js runtime.",
)
The approach is simple: just add "runtime": "nodejs" to the arguments passed to invoke().
For TypeScript, you would use "language": "typescript".
Conclusion
When you want to bring Node.js-based code to the Code Interpreter, this is definitely an option to consider.
While Strands Agents' built-in tools don't support this at the time of writing, you can create a custom tool using code_session.
I hope this article was helpful. Thank you for reading!