imux is designed to get you from intent to execution fast, without scattering the workflow across multiple apps. Use this guide as the baseline operating manual for local projects, remote hosts, file editing, source visibility, and supervisor-driven work.
Download the current macOS build from the imux website and install the app.
Open imux and create a workspace from a local folder, or start from a configured SSH target.
Set your LLM provider and model in Settings before you hand a task to the supervisor.
Use the right-side explorer and editor to keep files, paths, and task context visible while the terminal remains primary.
Most teams do better when imux is used as a repeatable operating surface rather than a one-off prompt box. These patterns keep the terminal primary while reducing drift.
Use one workspace per repo, keep Git visible, and let the terminal drive the task while files stay open beside it for verification.
Treat each SSH host like a first-class workspace with the same discipline you would apply locally. Remote work gets safer when path awareness and authentication state are visible.
Do not rely on generated output alone. imux works best when the operator quickly checks files, paths, Git state, and command results before the next step is approved.
When several tasks are moving at once, the supervisor should be used to keep goals bounded and progress interpretable rather than to produce abstract commentary.
imux is optimized around a workspace model. The workspace should represent one concrete project or one concrete remote host so the terminal, files, browser tasks, and supervisor all reference the same operating context.
The explorer is not decorative. It is the fastest way to inspect project shape, open files, confirm paths, and stay oriented while the terminal conversation is active.
imux includes in-workspace file viewing and editing so you do not have to keep bouncing out to a second editor for every small change or inspection pass.
The supervisor works best when you give it a concrete target, enough repo context, and a bounded objective. It should reduce ambiguity and compress the next move into a plan that can actually be executed.
imux is most useful when Git state stays visible during execution rather than becoming an afterthought at the end of the task.
Do not treat upgrades as a blind overwrite. imux should be updated with the same discipline you apply to any other developer tool that controls project context, remote access, or model settings.
A few habits change imux from a promising shell wrapper into a much more reliable command center.
Most slow starts come from vague goals, not from missing features. A short, concrete brief usually gets imux into execution mode fast.
When imux feels slow, noisy, or unreliable, the fix is usually operational rather than magical. These are the first checks worth making.
Most remote failures are caused by incomplete authentication, mismatched SSH config, or trying to browse files before the connection has fully settled.
This usually means the workspace goal is too broad or too many unrelated paths and tasks are sharing the same surface.
That usually means it is missing a bounded objective, fresh file evidence, or a clear signal about what counts as done.
