Coder · Transcript · · Updated
Using Claude Code with Coder – Transcript
Video by Coder · Watch the original on YouTube
Summary
AI-generated from the transcript. Verify details against the source video.
- Running Claude Code locally on a machine can lead to productivity drains and risks like prompt injection or potential damage.
- Coder provisions remote workspaces using Terraform where Claude Code can run in an isolated environment with a pre-installed repository.
- LLM calls made by the agent are filtered and audited through Coder's AI governance layer, which acts as a gateway and firewall.

Use this video with Pro
Reading, copying and transcript downloads are free. Create saved AI results for this video with a signed-in Pro account ($9/month).
Transcript
Search ignores accents. All transcript text stays visible.
Hey there. I'm Ben. I'm a product manager with Coder, and today I'm going to be walking through how and why you might want to use Claude Code with Coder instead of having to do it on your local machine. So, for starters, I wanted to show a little bit of an introduction of Claude Code and how it can be a little bit painful or even risky to run it on your local machine.
So, for those of you don't know, Claude Code is a tool that you can run in your terminal that can do coding on your behalf. So, for example, I can ask it to explain this code base, and it's going to read the files inside of this code base that I have cloned, and it'll tell me about it. So, I actually have Coder cloned and it's going to tell me a little bit about Coder's architecture and what um it can do. Now, you can have it write files and read files and do all that fun stuff, but, you know, you can't really get a lot of value out of it unless you can
actually build the project and try it yourself. So, I'm going to ask it to build the project. And what we'll notice first is one of the first kind of pain points with using Claude Code locally, which is you have to constantly give the agent, you know, approval to do certain things. For example, running a command.
Now, don't get me wrong, this is a good thing. I don't want my agent to be running a bunch of commands on my computer, but it can also be a huge drain on productivity because you have to constantly keep babysitting the agent and giving it approval to do things.
Now, the other thing that's um you know, going to happen here is it's telling me that, you know, my computer isn't actually set up for all of the dependencies and and kind of requirements that I need to actually build the project, which is, you know, one of the second downsides of running it locally, which is I don't really have a pre-baked dev environment to get this work done with. And, you know, it's telling me to, you you know, install these tools or it's actually offering to do it on my behalf. Now, this can be really risky cuz it's going out to the
public internet, downloading a bunch of packages, um and there's all sorts of risks here in either messing up my computer or getting susceptible to something called prompt injection, which means the agent's trying to do something right, but it runs into a malicious source on its way and then ends up doing something really destructive either to my, you know, computer or leaking credentials or doing like all sorts of things that I don't want it to do.
So, now, before we um show you kind of Coder, let's walk through the architecture of Coder and how it works and how it's a little bit different. So, for starters, the developer client isn't going anywhere. My my laptop is still here. However, there's no local code and no local agents, and instead the user is using either browser, VS Code, JetBrains, or SSH to kind of connect into Coder, which is actually run um on a customer-managed um you know, server
or instance. So, in this example, we're using AWS with Kubernetes, but it can also run on premise and even air-gapped or on any other cloud provider. From there, there's the Coder server, which handles things like the workspace life cycle, um authentication, and provisioning.
So, it can provision a a workspace, which then actually has the cloud code CLI as well as the source code, the um you know, IDE and terminal, as well as a network policy that can kind of prevent um the agent from accessing potentially malicious sources on the internet.
Um from there, all, you know, LLM calls that the agent is doing is actually being filtered and audited through an AI governance layer, which is a gateway as well as a firewall, which can monitor things like network traffic. And then it finally makes it to, you know, the AI provider as well as any approved network destinations, such as um Git or internal registries or whatnot. Um in this example, it has AWS Bedrock, but it could also go directly to the um uh Anthropic API.
Um and then there's also a database as part of Coder, you know, there there needs to be a database to be able to hold, you know, things like the like the workspaces. So, that's Coder's architecture. You know, no more Claude code on the laptop. Claude code runs in these isolated workspaces, sometimes referred to as sandboxes, and all of those calls go through AI governance into an AI provider of choice.
The other thing that's pretty cool is it can handle things like MCP management on your behalf, as well as things like auditing and firewalls. So, now let's go into Coder itself. And we'll see a prompt here to create a workspace. And there are a couple of different templates that the platform team has set up. We'll start with the golden template.
We'll give the workspace a name, and we'll create it. And what's happening here is essentially Terraform is being used to provision this remote resource. And once this spins up, we can see that we have some CPU usage already, some RAM usage, as well as a disk. So, you can kind of start to see that this is, you know, not my my local CPU, but this is actually a remote instance.
We can open up Code Server, which is a web-based IDE. So, we can do this, you know, on a on a laptop if we wanted to. And we can do our Claude from here. So, we can type in Claude. It's asking, do you trust this folder? I do.
You can also see a warning here. Now, this is a warning I could have bypassed, but I actually wanted to show you that this is happening. So, Claude is running in bypass permissions mode. In bypass permissions mode, Claude will not ask you for permission. Permission. This should only be used in a sandboxed container or VM with restricted internet access.
It can only be restored easily restored if damaged. So, we actually are in both of those cases, as I showed in the architecture diagram. It's not running in my laptop. It's running in a sandboxed container VM with restricted internet access. So, I can accept this, and now I can ask it to do things like clone Coder and build the project.
I should have actually built the template that already had the code base in, but you know, nonetheless, it should know what it means by cloning coder. Um and it should Oh, actually, it has it. Okay, cool. It already has it. I just I just missed it when I was giving the sidebar. So, it already has the repo pre-installed in it, which is awesome.
It's loading, you know, all of the documents that it needs to to do it. It says the tool chain's already in place, which is much faster that we're doing, and we're building the project. So, that's pretty awesome. Um the other thing that we could do that I don't think we had um installed, but we could show off is the cloud code extension.
This is something that could have also been pre-installed into the workspace, but this is for people who are maybe, you know, less comfortable using the terminal, but still want to start using things like cloud code, where, you know, I can actually do sessions right here in the sidebar. Um the other thing that I kind of just skipped over, but is super important, is I didn't have to authenticate into cloud code, um because everything is going through coder's AI gateway. Um so, now might be a good time to kind of Well, here we go. Here's the little cloud thing. But, now might be
it's good time to kind of pivot into the administration side of things, where we can actually start to view these sessions. So, we can see the session here that started with clone coder and build the project. Um this is something that an auditor could use, you know, in the case of an incident to figure out what happened. We can see the the user that did it, the client they used, the provider, as well as how many tokens.
Um and you know, the really important part here is we can also monitor the agentic loop. So, if an agent did something um potentially destructive or potentially interesting, you can start to see the tool calls that it began um running and the number of tokens each tool call consumed. So, this this data is really useful to monitor in the UI, but I think more importantly, people can export this into a seam, so they can, you know, audit it and manage it in the um
uh in in some API, or you know kind of more systematically and you know this is really only scratching the surface of AI governance but it kind of shows you the power of starting to run these things remotely as opposed to locally and the other thing that's pretty cool too is this is only one workspace. I can create all sorts of workspaces and run all sorts of agents in parallel with a piece of mind knowing that they're running in sandbox you know
workspaces and they have restricted tool sets and everything's being essentially governed managed through Coda.