User guide / Workspaces and persistent sessions

Starting a workspace

Development reference · View source

Finding the workspace. Runyte walks up from the launch directory to a Git root, or else to a workspace state directory (.runyte/). See Where workspace state lives .

--init DIRECTORY creates the configured state directory (.runyte/ by default) in exactly that directory, prints how to open it, and exits without starting the editor:

initialized a workspace in /path/to/project
open it with: runyte /path/to/project   or   runyte --mux /path/to/project

• An existing state directory is used as is, never reset or removed, and the output says it is already a workspace.
• It picks the named directory even when an ancestor has its own state directory.
• It refuses a state directory that would overlap your configuration or cache directories.

mode: mux makes a bare runyte attach like runyte -a.

• Launches naming a target — a file or a directory, including runyte . — run in ide mode in this process, so their relative paths and +LINE[:COLUMN] positions keep ordinary meaning.
• --mux reads its argument as a workspace, not a file.

runyte -a WORKSPACE uses the same selector as the lifecycle commands (see Selecting a session ).

• A session that is not running is started first.
• An existing directory unknown to the catalog names that exact directory: Runyte creates its state directory if needed and starts its session. :session-attach DIRECTORY and the explorer’s Tab s do the same.
• A bare runyte -a uses the workspace of the current directory, and refuses when there is none.

Only one interactive TUI may be attached at a time. Separate control connections can still manage the host.