Request for native devcontainer support in Antigravity to enable seamless development in containerized environments. Devcontainers are essential infrastructure for professional software development, and their integration would significantly enhance Antigravity’s capabilities for modern development workflows.
Background: Why Devcontainers Are Essential
1. Environment Consistency
“Works on my machine” problem solved: Devcontainers ensure every developer, CI/CD pipeline, and production environment uses identical configurations
Reproducible builds: Dependencies, tools, and runtime versions are locked and version-controlled
Onboarding efficiency: New team members can start contributing in minutes, not days
2. Professional Development Requirements
Dependency Isolation
Projects often require conflicting versions of Python, Node.js, or system libraries
Devcontainers prevent conflicts between projects without manual environment switching
Essential for teams maintaining multiple projects or microservices
Security & Compliance
Isolated environments reduce attack surface
Compliance requirements often mandate reproducible, auditable build environments
Container scanning and security policies can be enforced at the infrastructure level
CI/CD Parity
Development-production parity: The same container definition used locally runs in CI/CD
Eliminates deployment surprises from environment differences
Faster debugging of pipeline issues3. Industry Standard Practice
GitHub Codespaces uses devcontainers as its foundation
Microsoft promotes devcontainers as best practice across all their development tools
Major open-source projects (Kubernetes, VS Code, TensorFlow) provide devcontainer configurations
Enterprise adoption: Most Fortune 500 companies standardize on containerized development
Devcontainers bundle all of these together with proper version control.
Remote Development
Teams work across different operating systems (macOS, Linux, Windows)
Devcontainers provide identical environments regardless of host OS
Cloud-based development (Codespaces, GitPod) relies on devcontainers
Current Limitations in Antigravity
What Doesn’t Work Today
No container awareness: Antigravity can only access the host filesystem
Cannot execute in container context: Commands run on host, not in the development environment
Manual workarounds required: Users must use docker exec or VS Code separately
Broken workflow: Context switching between Antigravity and VS Code/terminalImpact on Productivity
AI assistance limited to host environment: Can’t help with container-specific issues
Code suggestions may be incorrect: Without access to container dependencies, suggestions might not work
Testing requires manual steps: Can’t run tests in the proper environment
Debugging friction: Can’t inspect or debug containerized applications effectively
Proposed Feature: Native Devcontainer Integration
Core Capabilities
1. Detect and Connect to Devcontainers
✓ Auto-detect .devcontainer/devcontainer.json
✓ Connect to running devcontainers
✓ Start devcontainers automatically if not running
✓ Switch between host and container contexts
2. Execute Commands in Container
All run_command calls execute inside the devcontainer
Access to container’s installed tools, dependencies, and environment
Proper path resolution within container filesystem
3. File System Access
Read/write files within the container context
Access to volume mounts and container-specific paths
User opens project with .devcontainer/devcontainer.json
Antigravity detects configuration and prompts: “Start devcontainer?”
User confirms, Antigravity runs container and connects
All subsequent AI assistance happens in container context:
Install dependencies: pip install runs in container
Run tests: pytest uses container’s Python environment
Debug issues: Antigravity inspects container logs
Code suggestions: Based on container’s installed packages
UI Indicators
Status bar: Show “devcontainer: active” or “host”
Command palette: “Switch to devcontainer” / “Switch to host”
Settings: Configure default behavior for devcontainer projects
Use Cases
1. Multi-Service Applications
Project with FastAPI backend + React frontend:
Antigravity helps modify backend code
Runs API tests in Python 3.12 container
Installs npm packages in frontend container
All without user manually running docker exec
2. Legacy Code Modernization
Work on Python 2.7 project in container while using Python 3.12 on host
Antigravity assists with migration, testing in both environments
3. Cross-Platform Teams
macOS developer collaborates with Linux developers
Devcontainer ensures Antigravity’s suggestions work for everyone
4. MLOps & Data Science
Jupyter notebooks in container with GPU support
Antigravity helps with data processing, model training
Container includes CUDA, TensorFlow, PyTorch at specific versionsTechnical Implementation Considerations
Option 1: Dev Containers CLI Integration
# Antigravity could use the official CLI
npx @devcontainers/cli exec --workspace-folder . <command>
Option 2: Docker API Direct
Use Docker SDK to manage containers
More control but more complex
Option 3: VS Code Remote Extension Protocol
Leverage Microsoft’s existing remote development protocol
Maximum compatibility with existing devcontainer ecosystem
Competitive Landscape
Tools with devcontainer support:
VS Code: Full native support
JetBrains IDEs: Remote development support
GitHub Codespaces: Built on devcontainers
Cursor IDE: Devcontainer support
Antigravity: Not yet supported
Missing this feature puts Antigravity at a disadvantage for professional development teams.
Success Metrics
After implementation, users should be able to:
Open any devcontainer project and have Antigravity “just work”
Execute all AI-assisted commands in container context
Never need to manually run docker exec
Develop equally well on macOS, Linux, and Windows
Match the development experience of VS Code + Copilot/CursorPriority: HIGH
Why This Is Critical
Professional developers expect this: It’s standard practice in 2025
Blocks enterprise adoption: Companies won’t adopt tools that don’t support their infrastructure
AI benefit amplified in containers: Reproducible environments make AI suggestions more reliable
Ecosystem alignment: Makes Antigravity compatible with GitHub Codespaces, dev containers standard
Conclusion
Devcontainer support is not a “nice to have” feature - it’s essential infrastructure for modern professional development. Without it, Antigravity cannot fully serve:
Enterprise development teams
Open-source projects
Multi-service applications
Cross-platform teams
Cloud-native development workflows
Request: Prioritize native devcontainer integration to make Antigravity a truly professional-grade development tool.
Hi @Ren_Silva Welcome to the forum!!!
Thank you for your feedback. We appreciate you taking the time to share your thoughts with us, and we’ll be filing a feature request.
I tried now a few times to use Antigravity and it never worked. Devcontainers are working in Antigravity but the browser tool can not setup the chrome extension and also not use it if it was setup in a Antigravity session that was not within a devcontainer.
It is so dissapointing that google releases Antigravity without a working devcontainer support. Antigravity in the current state is basically useless .
I hope devcontainers+Antigravity Chrome extension will be supported soon.
I’ve had a similar experience, but if I want to rebuild the devcontainer, I have to do it from VS Code. Sometimes it has trouble starting the devcontainer and just keeps loading. In those cases, if I close and reopen Antigravity and then reopen it in the devcontainer, it works. Everything works more or less fine, except for the browser agent, which isn’t able to connect to the host’s Chrome instance.
I am in dire need of this feature. I implore you to ensure that the GPG key for signing commits is not overlooked. Cursor has fallen short in this regard. It is exceedingly frustrating to be compelled to commit from the host machine due to the dev container’s inability to do so.
Thank you in advance! Google possesses all the necessary attributes to dominate this market!
I agree with most of the people in this forum. Without complete support for devcontainers this is a toy and not useful to coders that need the flexibility of multiple environments.
My customers use everything from php 7 to php 8 and ever other product under the sun (it seems at times) … devcontainers make this type of “hired gun” developer possible for me.
I have almost no development tools loaded directly on my machine and this is the way I like it.
Looking forward to the inclusion of devcontainers!
I also need this feature so much. Cursor, for instance, does not support devcontainers (they have something similar, but I didn’t manage to make it work) so I had to go back to VS Code. I’ve heard Antigravity is the next big thing, but it becomes unusable for us at this point.
These are our everyday uses cases:
With Intel OneAPI as base image, we compile libraries such as netcdf, netcdf-fortran, zlib, pnetcdf, hdf5, etc., so I can build, debug, profile and test a FORTRAN application.
A compiled, ready-to-use numerical ocean model (ROMS, Delft3D) along with its dependencies (gfortran, netcdf, openmpi) and tools (CDO, ncview) on a specific Ubuntu version (in some cases we need dependencies that were deprecated after Ubuntu 20.04). On top of these, there is a uv (Python) environment with synced dependencies.
In the cases above, we reuse their Docker image definitions in Github Actions to run tests when creating and merging a PR; and after making a new release, we deploy containerized applications that prepare and execute such numerical models.
Hello,
I hope it helps, I managed to get devcontainers working. There were 3 problems:
If you are already inside WSL, the Attach to Running Container option is not displayed when doing Ctrl+Shift+P
It looks like the line “when”: “!remoteName” from C:\Users\AppData\Local\Programs\Antigravity\resources\app\extensions\antigravity-dev-containers\package.json
You need to have wget installed in the container
You must change the line of the server installation script, which is located in C:\Users\AppData\Local\Programs\Antigravity\resources\app\extensions\antigravity-dev-containers\dist\extension.js from if [ ! -z $(which wget) ]; then
for if command -v wget >/dev/null 2>&1; then
Really need proper devcontainer support - need to be able to connect to a remote server via SSH and then open a container on the remote server. This workflow works in Cursor and VS Code, but not Antigravity
I was excited to try Antigravity today but immediately ran into issues trying to get my devcontainer working. I don’t see the extension in the open vsx marketplace either.
Devcontainers are wonderful when paired with AI, I think this is a very high ROI feature for your team to prioritize.
For me it’s a must for security reasons. Call me a sceptic but I do have some misgivings about letting AI run code and arbitrary commands with full access to my filesystem, while generating them based on stuff it finds on the internet. I would prefer to run this code and these commands in the sandbox of a dev container.
You may say I should review the code and the commands before I run them but you know as well as I do that no human being is able to do this every time. I don’t trust whitelisting either, it’s got so many loopholes. The only way to be productive with AI is to let it run freely, but without a sandbox it’s a bit scary.
Hello, thank you for sharing your experience with Antigravity.
Regarding running Devcontainers, please review the findings of @Pablo_Bcn above and the response of @iTazB in this thread.
If you continue to experience issues, please share more details regarding your steps and the specific error logs.
I have been running into similar issues as others with the Antigravity supported Dev Container experience. My containers that “just work” in VS Code do not work in agy. This is a huge blocker for adoption due to the security boundaries and DevX that Dev Containers offer - especially for AI dev tools.
Recommendations:
Hotfix the wget server install script bug - users should not have to develop containers around agy limitations as a development platform
Add support for “Rebuild” and “Rebuild without Cache” - this functionality is key to those who maintain Dev Containers (this also feeds into the bug listed at #3)
Fix the follow issue detailed below - Remote connection stalls after initial container build
Connection Stall Bug:
I have spent the better part of a a day and a half trying to work around this agy limitation, but there is something else going on that is causing the issue.
Basically, when I perform an initial “Reopen in Container”, agy initiates a container build on behalf of the user. After which, it should install the remote server in the container. It SHOULD then connect to the container. And finally, install the defined extensions in the container.
I am seeing in Developer Tools that after the container is built, agy is showing: INFO [LocalProcess0][resolveAuthority(dev-container,1)][30001ms] waiting...
This process seems to never be able to get the websocket it needs in order to connect to the container and complete the process. I CAN perform a “Reload Window” at the point in which the connection stalls and it will eventually get the socket and connect: INFO [LocalProcess0][resolveAuthority(dev-container,1)][7784ms] returned WebSocket(127.0.0.1:53833)
Workaround Limitations
This however still presents an issue because this blocks the extension installs and does not finish setting up the container (basically just opens a 2nd connection without the devcontainer setup finishing). This means that the development container does not match what is defined in the .devcontainer definition and does not support extensions - including functionality like linting and formatting - by default.
Environment
OS: MacOs Tahoe 26.2
Chip: Apple M3 Pro
Agy Version:
No not yet I don’t think. I have some bandaid solutions I’m using right now that’s a rebuild script that takes care of the container rebuild prior to running Reopen In Container. I also have a script that installs extensions that I run after connecting to the container to make that easier. Definitely not ideal, but gets me like 90% of what I need.
This needs to be moved to the top of the feature support list.
Like others have called out, Antigravity is a toy without it, and it will certainly lead to it NOT being adopted by enterprises who have baked in 6+ years of workflows with devcontainers (for all the positive reasons listed by OP).
.