Remote workspaces
Remote work in imux uses the same workspace model as local work, but the risk profile is different. Treat each SSH target as its own operating surface with explicit path checks, real remote file browsing, and a visible objective.
# Confirm the target before changing state
ssh prod-api 'hostname && pwd && git status --short'
# Keep evidence in the imux workspace
icc notify --title "Remote check" --body "prod-api shell connected"
icc sidebar log --level info "Verified host identity and working directory"Start from a known SSH target
Use named SSH config entries whenever possible. A named target is easier to audit, easier to reconnect, and less likely to be confused with a similar host.
- Confirm the host alias before connecting.
- Use a separate workspace per host or environment.
- Do not mix production, staging, and local shells in the same workspace.
Wait for shell and explorer state to agree
Remote safety comes from path awareness. Do not browse or edit remote files until the shell connection and remote explorer both reflect the intended target.
- Check `pwd`, host identity, and branch or deploy directory before editing.
- Use the remote explorer to inspect real remote contents rather than assuming a local mirror is accurate.
- Keep logs, config files, and current task notes visible while operating.
Use small, reversible steps
Remote workflows should move in smaller increments than local coding work. imux gives you enough context to inspect before acting and enough automation to capture evidence after acting.
- Read the file or log before issuing a command that changes state.
- Prefer dry runs, status checks, and narrow restarts over broad commands.
- Capture relevant output in the workspace before handing off or closing the session.
Separate operations from agent experimentation
Agents can help with remote diagnosis, but production-facing commands should remain operator-approved. Keep exploratory agent work in a dedicated workspace when needed.
- Use one workspace for investigation and another for production action when the task is risky.
- Ask the agent for a command plan before execution.
- Run the final command yourself when the blast radius is meaningful.
Before a remote change
- Confirm the SSH alias and host identity.
- Confirm the working directory and environment.
- Open the file, log, or config being acted on.
- State the rollback or recovery command if one exists.
- Capture the result before moving to the next action.