Skip to content
AI Primer
workflow

OpenCode adds CloudShell workflow that reuses AWS auth and Bedrock models

OpenCode can now run from AWS CloudShell via npx and inherit AWS auth plus Bedrock models; the same update also brought Firecrawl, India billing, and heap-snapshot debugging. It is becoming a real ops workflow, not just a local terminal toy.

3 min read
OpenCode adds CloudShell workflow that reuses AWS auth and Bedrock models
OpenCode adds CloudShell workflow that reuses AWS auth and Bedrock models

TL;DR

  • OpenCode now runs inside AWS CloudShell with a three-step flow: npx opencode-ai, inherited AWS auth, and automatic access to Bedrock models, according to the CloudShell post.
  • The change pushes OpenCode beyond a local terminal assistant and into cloud ops territory; in a separate workflow note, its creator also pointed to /review as a local code-review path that can run code rather than forcing everything through a GitHub PR UI.
  • OpenCode also picked up Firecrawl integration, with the plugin announcement saying agents can now scrape, search, and browse through the toolchain.
  • On the operational side, a maintainer support thread asks users hitting memory problems to generate a heap snapshot from the command palette and upload it, while the India billing update adds UPI autopay for OpenCode Go at ₹900/month.

What shipped for AWS and Bedrock?

The core update is a new AWS-native bootstrap path. In the launch post, OpenCode's maintainer described the flow as: open CloudShell, run npx opencode-ai, and use an environment that "already is authed with aws" and "will pickup bedrock models." That means the tool can start inside an AWS-managed shell without a separate local credential dance.

A repost from the OpenCode account confirms the same sequence, which matters because it frames the feature as product behavior rather than a one-off hack. The practical change is that Bedrock-backed model access now sits directly in the shell session where an operator is already working, instead of requiring a separate local setup.

Why this looks more like an ops workflow

The CloudShell path changes where OpenCode can run, but the adjacent workflow signals show what the team wants it to do there. In the review post, the maintainer argued that LLM review should not require users to "push code up" just to pass through "awkward github ui hacks," and said OpenCode's /review can also "run your code to check things." That is a stronger claim than plain inline review: it suggests local or shell-based validation as part of the review loop.

Taken together, the Bedrock-aware CloudShell flow and the /review positioning make OpenCode look less like a local terminal toy and more like a lightweight operator interface for cloud changes, repo review, and scripted checks. The joking "cause a sev1 incident" line in the original post underscores the target environment: people are expected to point this at live AWS contexts, not just side projects.

What else changed around the tool

OpenCode also expanded its tool surface. According to the Firecrawl plugin post, installing firecrawl-cli lets agents "scrape, search, and browse," which gives OpenCode a clearer path to web retrieval tasks from inside the same agent session.

The reliability story is still evolving. In the support request, the maintainer said there are "occasional complaints about memory issues" and asked affected users to press Ctrl+P, choose "Write heap snapshot," and then follow upload instructions via the upload endpoint. That is a concrete debugging hook, not just an acknowledgment of bugs. Separately, the billing update says UPI autopay is now live for OpenCode Go in India at ₹900 per month, which removes some subscription friction for that market.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 3 threads
TL;DR1 post
What shipped for AWS and Bedrock?1 post
What else changed around the tool1 post
Share on X