cmdop mode

cmdop runs in one of two modes — prod (against the production cluster) or dev (against a developer cluster). Each mode has its own token file, its own active workspace, and its own endpoint base.

Show the current mode

cmdop mode

mode:       prod
endpoint:   api.cmdop.com
token:      ~/.cmdop/token_prod.json
workspace:  acme-prod

Switch mode

cmdop mode dev          # explicit
cmdop mode prod
cmdop mode toggle       # flip between the two

Switching mode reloads the daemon — the local SDK socket stays up but the relay reconnects against the new endpoint with the new token.

Why per-mode tokens

Keeping tokens separate prevents accidentally hitting prod with dev credentials (or vice versa). Both tokens are workspace-scoped at issue time.

Effects of a mode switch

When you flip mode:

1. The daemon is asked to reload (cmdop agent restart happens implicitly).
2. The local SDK socket stays up — clients reconnect to the same socket, no client restart needed.
3. The relay disconnects and reconnects against the new endpoint with the new token.
4. The active workspace switches to whatever was last active in the destination mode.
5. cmdop machines, cmdop connect, and pickers now show machines from the destination workspace.

Inline override

For one-off commands without flipping global state:

cmdop --mode=dev machines
cmdop --mode=dev connect exec dev-vps-1 -- whoami

Mode in scripts

Switching mode mid-script is reliable:

cmdop mode prod
cmdop connect exec prod-server -- ./deploy.sh
 
cmdop mode dev
cmdop connect exec dev-vps-1 -- ./smoke.sh

Or pass --mode=... per call to avoid touching shared state.

Troubleshooting

• “Token not found for mode dev” — cmdop mode dev, then cmdop login.
• Wrong workspace after switch — each mode tracks its own active workspace; use cmdop connect workspace use <ws> after switching.
• Endpoint unreachable in dev — confirm VPN / network access to api-dev.cmdop.com.

Related

• Authentication
• Workspaces
• Agent Daemon
• Developer Tools