Repository navigation
Choosing Dockiva Engine points the docker CLI at it - #69
Merged
Merged
Conversation
Selecting Dockiva Engine (or starting it on launch) creates or repairs the "dockiva" docker context for ~/.dockiva-engine/docker.sock and makes it current, the way Docker Desktop and OrbStack take the context when they start. The replaced context is saved beside settings.json and given back when another engine is chosen, unless the user switched contexts since.
chandarith-chea
force-pushed
the
dockiva-cli-context
branch
from
November 14, 2026 04:32
b9a00c5 to
030de60
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Choosing Dockiva Engine only changed what the app itself talks to. The
dockerCLI (and Compose, buildx, act, and IDEs that follow the CLI's context) kept using whatever context was current, usually OrbStack or Docker Desktop. Sodocker psin a terminal showed another engine's containers. Thedockivacontext, where one existed, had been created by hand and still pointed at the pre-rename~/.vmfreepath.Change
docker_cli_context.go:useDockivaCLIContextcreates or updates thedockivacontext for<engine home>/docker.sock. It saves the current context name to~/Library/Application Support/Dockiva/previous-docker-contextand runsdocker context use dockiva.restoreDockerCLIContextswitches back to the saved context, but only ifdockivais still current. If the saved context no longer exists, it switches todefault. It then deletes the file. When there is no file, it runs no docker command at all.DOCKER_HOST/DOCKER_CONTEXT, because the app setsDOCKER_HOSTfor itself.SelectEngineBackend("vmfree")switches the context after the engine is up. Launching with Dockiva Engine chosen (AutoRecoverEngine) switches it even whenstartEngineOnLaunchis off, after a successful start when it is on. Every other backend restores first, beforeexternalreads the active context.Same model as Docker Desktop and OrbStack: whichever engine started last owns the context. If OrbStack starts after Dockiva, it takes the context back until the next Dockiva launch or select.
Test
TestDockivaCLIContextTakesAndGivesBackruns the real docker CLI against a temporaryDOCKER_CONFIG. It covers: repairing a staledockivacontext, switching to it, selecting twice, restoring to the original, and a second restore leaving the user's own choice alone. It is skipped when there is no docker CLI.go test .passes.On a real Mac, a core built from this branch was run against the real
~/.docker, with Dockiva Engine running and runner containers live:The hand-made
dockivacontext (~/.vmfree/docker.sock) was repaired to~/.dockiva-engine/docker.sock. Runner scripts that usedocker --context dockivakept working.