You told the agent to fix something inside your project's dev container. It worked for a while, ran a command or two, and reported back that the fix landed. So you pop open a second terminal to check for yourself — maybe outside the Dev Containers window in VS Code entirely, maybe just a plain system shell sitting next to it — and you run the exact same command.
It disagrees. Not a slightly different answer. A flatly different one: the test still fails, the version string is still the old one, the bug is still sitting right there.
Same file. Same command, typed the same way. Two different answers, and neither terminal is lying to you.
The reassuring part, up front: nine times out of ten, the fix is fine — you just checked it from a process that was never going to see it. Once you know why, the worry goes away, so here is why.
What you actually have here
If you've got a '.devcontainer' folder in your repo — team boilerplate, a starter template, a GitHub Codespace — and you've just gotten your coding agent running inside it, this is the setup you're in. Anthropic's own dev container docs lay out the architecture plainly: an editor that supports the Dev Containers spec, like VS Code or Codespaces, connects to a Docker container, and "the integrated terminal, language servers, and build tools all run inside the container rather than on your host." Claude Code, running in that same container, "sees the same files, dependencies, and tools as the rest of your project's toolchain."
That second terminal you opened — the one that disagreed — almost never runs inside that same container. If it's a plain system terminal, or an editor window that isn't attached to the Dev Containers session, it's a completely different process talking to a completely different PATH, a different Node or Python install, different globally installed packages. It's not part of the toolchain the agent was just using. It just happens to be pointed at the same folder.
This holds whether the container is running locally through Docker Desktop or remotely through a GitHub Codespace — same architecture either way, just a different machine hosting the box. What matters isn't where the container physically runs, it's which terminal window is actually attached to it. Two tabs that look identical in your editor's UI can be pointed at two completely different environments, and nothing on screen tells you which is which unless you check.
The wrong way to picture this
The instinct here is to picture two boxes, each holding its own copy of the file — the container's copy, which got fixed, and your copy, which didn't. That model is wrong, and it'll send you hunting for a sync problem that doesn't exist.
The docs are specific about this too: the host repository is "bind-mounted into the container as the workspace." A bind mount isn't a copy or a sync — it's the same inode (the same single entry on disk, not a duplicate of it), the same bytes, visible at two different paths. When the agent edits a line inside the container, that edit is not "pushed" anywhere. It's just there, immediately, in the file your outside terminal is also reading. There is one file. There was always one file.
One file, two processes
Here's the same shape of mismatch, reproduced on one machine so you can watch the file stay identical while the answer changes. I can't spin up a full Docker container inside this write-up, but the mechanism is exactly the same one your two terminals hit: two different Python interpreters, resolved off two different PATHs, reading one unchanged script.
# check.py import cowsay cowsay.cow("fixed")
Run it from a plain system Python that's never had this package installed — this is your "outside" terminal:
$ md5sum check.py ee940d9c50a6da3ab1a863a12d492741 check.py $ python3 check.py Traceback (most recent call last): File ".../myrepo/check.py", line 2, in <module> import cowsay ModuleNotFoundError: No module named 'cowsay'
That's a plain crash — the module doesn't exist as far as this interpreter is concerned. (That top line shows the file's absolute path, not the bare check.py you typed — same crash wherever you run the script from, only how much of the path you see changes.)
Now run the identical file — I checked, the checksum doesn't move — from a Python that has the package installed, standing in for the toolchain your agent was actually using:
$ md5sum check.py ee940d9c50a6da3ab1a863a12d492741 check.py $ ./envA/bin/python check.py _____ | fixed | ===== \ \ ^__^ (oo)\_______ (__)\ )\/\ ||----w | || ||
Same checksum, both times. One interpreter crashes on the import, the other draws you a cow. Nothing about the file changed between those two runs — what changed is which program read it, because 'which python3' resolves to a different binary depending on which PATH answers the question:
$ which python3 /usr/local/bin/python3 $ ./envA/bin/python -c "import sys; print(sys.executable)" .../myrepo/envA/bin/python
That's your two terminals. The container's shell has Node, Python, and whatever dependencies your devcontainer.json installed when the image was built. Your plain system shell has whatever's been sitting on your machine since whenever you last set it up — often an older runtime, often missing the exact package the fix depended on. 'which' is doing real work in both of those commands: it's not printing a version, it's telling you which binary on disk actually answers to that name in this particular shell's PATH. Same command typed, two different programs answering it, because PATH resolved to two different places.
Why this matters
This isn't a warning about agents being unreliable. The agent's report can be completely accurate about what it just watched happen — inside its own process, against its own installed toolchain — and your outside check can also be completely accurate about what your process saw, which is a different toolchain pointed at the same bytes. Both terminals are telling the truth. They're just not describing the same execution.
That's a sharper failure than "the AI was wrong," and it's a real one. Issue #26623 on the Claude Code repo is a developer who bind-mounted their '~/.claude' config directory into a VS Code dev container, set 'CLAUDE_CONFIG_DIR' to point at it, confirmed the directory's contents matched what was already on their local machine, and still watched the CLI act like none of it existed, dropping them into the first-run welcome flow as if nothing had ever been configured. Matching contents, still a mismatch, because "the file is the same" was never the part in question. What differs, every time this bites someone, is which process is doing the reading and what environment it was launched with.
That's also why re-running the same command in an unattached terminal isn't a real test of whether the agent's fix worked. It's a test of whether that terminal's own toolchain happens to agree with the container's. Most of the time it will, since plenty of dev containers deliberately track the host's Node or Python version to avoid exactly this surprise. But "usually the same" is doing real work in that sentence, and the day your devcontainer.json pins a version or a dependency your host never installed, that quiet agreement breaks, and you're staring at two answers with no reason to trust one over the other just because it's the one you're used to checking.
What to actually check
When the agent's answer and your terminal's answer disagree, don't start diffing the file — it's almost certainly identical in both places. Check the process instead:
- Is this second terminal actually attached to the Dev Containers session, or is it a separate window, a separate tab group, or a plain shell you opened out of habit?
- Run 'which node' or 'which python3' (or whatever the fix touched) in both terminals and compare the paths, not just the version numbers.
- If the paths differ, check what's actually installed at each one — 'npm ls', 'pip freeze', whatever fits — before assuming the fix itself is broken.
That is the whole check: interrogate the process, not the file.
Final thought
Next time an agent tells you something's fixed and your own check says otherwise, run 'which' on whatever binary matters before you touch the code again. If the two terminals point at two different binaries, you've found the disagreement already — and it isn't the one you thought you were debugging. Then run the check one more time in the terminal that is actually attached to the Dev Containers session — the process the fix lives in — because finding which binary answers is the diagnosis, and running it in the right shell is the confirmation you opened that second terminal to get.