You correct it: "run that inside the Docker container." Works perfectly. Next turn, it forgets. And so you spend half the session being a human Docker router, translating every command the agent suggests into its docker exec equivalent. It's exhausting in a small, papercut sort of way.
@elyracode/docker is the fix. It teaches Elyra what your containers are from the moment a session starts, so you can stop being the middleman.
elyra install npm:@elyracode/docker
You need the Docker CLI. That's it.
The extension reads your docker-compose.yml (or compose.yml), sees which containers are running, and quietly slides that context into the system prompt:
# The agent now knows:
# - Which services exist (app, db, redis, nginx)
# - Which ports are mapped (8000:80, 3306:3306)
# - Which volumes are mounted
# - Which containers are currently running
From here on, commands that belong inside a container go inside a container. You don't have to ask, remind, or nudge.
This is the heart of it. When the agent needs to run something, it runs it in the right place:
Run the database migrations
The agent calls docker_exec against the app container with php artisan migrate. Not on your host. Inside the container where PHP, Composer, and the database connection actually live.
A few more examples that should feel familiar:
Run the test suite
Check what Node version is in the frontend container
Install the missing Composer package
Clear the application cache
You can be explicit when you need to be:
Run "redis-cli FLUSHALL" in the redis container
And there are sensible overrides for working directory and user when a container needs them:
Run "npm run build" as the node user in the frontend container
When something breaks, the answer is almost always sitting in the logs, waiting to be read. Instead of bouncing over to another terminal and squinting at docker logs, just ask:
Show me the last 50 lines of the app container logs
What errors are in the nginx logs from the last 10 minutes?
Check the database logs for slow queries
You get tail counts, time filters, and grep:
Show me PHP fatal errors in the app logs from the last hour
The really nice part: the agent reads the logs, understands the error, opens the right file, fixes the bug, and verifies by checking the logs again. One loop, no context switching, no copy-paste shuffle.
The agent can drive your stack:
Rebuild the app container
Restart the database service
Bring up the entire stack
Stop all containers
This earns its keep after Dockerfile changes. Edit a Dockerfile or a config, and the agent can rebuild and restart without you ever leaving the conversation:
Update the PHP Dockerfile to add the redis extension, then rebuild
The agent edits the Dockerfile, runs docker compose build app, and restarts the service. One prompt, three operations, done.
Only safe operations are allowed by default — up, down, restart, build, pull, stop, start, ps. No rm, no --force-recreate unless you pass it explicitly. Sharp edges stay sheathed.
The classic Docker mystery: your .env says DB_HOST=127.0.0.1, but the container is happily talking to DB_HOST=db. Or you added a new variable to .env and forgot to rebuild, so the container is still running yesterday's reality.
Check if my .env matches what the app container sees
The agent reads your host .env, runs env inside the container, and lines them up next to each other. You get three buckets:
Missing in container — things in your .env the container doesn't have. Usually a rebuild is needed, or the variable isn't passed through in docker-compose.yml.
Different values — same name, different value. The classic "works on my machine" generator.
Only in container — variables the container has that aren't in your .env. System noise is filtered out; what's left is the app-level stuff that snuck in via a Dockerfile or compose file and never made it back into your documentation.
> Check if my .env matches what the app container sees
Missing in container (2):
- STRIPE_WEBHOOK_SECRET
- PUSHER_APP_KEY
Different values (1):
- DB_HOST: host="127.0.0.1" container="db"
Only in container (3):
- COMPOSER_ALLOW_SUPERUSER
- PHP_OPCACHE_VALIDATE_TIMESTAMPS
- PHP_MEMORY_LIMIT
Now you know exactly why Stripe webhooks aren't firing inside Docker, and why your host tests can't reach the database.
For a quick glance without involving the agent:
/docker
Running containers, images, status, port mappings. Handy as a sanity check before you dive in, or right after a rebuild to confirm everything came back up the way it should.
Laravel Sail projects. Sail wraps everything in Docker, which is great until your agent starts trying to run artisan against host PHP that may or may not exist. With this extension, commands land where they should.
Multi-service stacks. App, Node frontend, database, Redis, queue worker — the agent knows which container each command belongs in.
Debugging "works on my machine" bugs. Host works, Docker doesn't? The env check finds the mismatch in seconds. The logs surface the real error. The agent can fix it without ever leaving the session.
Onboarding. A new developer runs docker compose up, installs the extension, and the agent already understands the project's plumbing. No more "remember to run commands inside the container" notes pinned to the README.
It doesn't reach for remote Docker hosts, and it doesn't speak Kubernetes. This is firmly about your laptop — your docker CLI, your docker-compose.yml, your local containers.
It doesn't replace your Docker workflow, either. It just lets the agent join you inside it, so you can stop being the translator between what the agent wants to do and where it should actually run.