Programs that outlive a session

What it is

Every session's commands run inside a container Windows calls a job object, created with a kill-on-close limit. Anything started from that shell joins the container, so when the session ends the container closes and everything inside it ends — including an AutoHotkey script or a helper app started a minute earlier. Nothing was broken; there was simply no way out of the container.

The fix is a road where the app starts the program instead. The app runs outside every session container, so a program it starts is not tied to any session's lifetime. It is still tied to the app's: when Omniscio quits, the program ends with it.

Where to find it

It is a request an agent makes to Omniscio's local control server, not a button in the window:

POST /programs/launch
{ "exe": "C:\\Program Files\\AutoHotkey\\AutoHotkey.exe",
  "args": ["C:\\scripts\\helper.ahk"],
  "visible": false }

GET /programs/launches lists recent launches and refusals. The one switch for the whole road is in Settings → CLI Control: start programs from the CLI. It ships on; switching it off makes the launch request answer "switched off" instead of starting anything, while the list of past launches stays readable.

How it behaves

• The program survives the session, not the app. Archiving the session leaves it running; a crash or force-quit of Omniscio may leave it running too, and the reply says so in plain words when the program could not be tied to the app's own cleanup.
• args is a list of separate values, never one command line, so nothing inside a path can be read as another command.
• Programs start hidden unless the request asks for a window.
• A session may keep six launched programs running at once. A seventh is refused with a plain explanation rather than quietly filling the machine.
• Every launch and every refusal is written down in a small ledger at ~/.amc/program-launches.jsonl, naming the session that asked, the program and the time. A session reading that list sees only its own rows; Omniscio itself sees all of them.
• A cloud session cannot use this road at all — it would start a program on your computer from a machine somewhere else. Those routes are refused for that whole tier.
• Long values are trimmed and secrets are scrubbed before they reach the ledger, so a token passed as an argument does not come back out of it.

Programs that survive quitting Omniscio

A program you were running yourself — a tray utility, a keyboard helper, a script that gives you a key you use all day — can be restarted by an agent and still be there after Omniscio closes. That is separate from the road above and off by default.

• It is the person's decision, never the agent's. The first time a session asks, a card appears in your inbox naming the exact program and the arguments it will run with, with two buttons: allow it for this session, or allow it from now on. Until you answer, nothing is started.
• Only your own, already-running programs qualify. Omniscio notes what you had running when the session began, and a restart counts only for one of those exact programs. A program the session itself started, a look-alike with the same name in another folder, and a program that appeared after the session began are all refused.
• Shells and script hosts are never handed back — cmd, PowerShell, wscript, Node, Python, Java, .NET and their relatives — even when they were already running.
• A restart works. Stopping the old copy first and then starting the new one is fine; eligibility does not depend on the old copy still being alive.
• It keeps running until you close it or restart the computer, exactly as if you had started it yourself.
• The setting is Settings → CLI Control → Let agents restart your programs so they survive quitting. It ships off. Nothing an agent can say or send turns it on; only your click does.

For agents

• The request body is { exe, args?, cwd?, visible? }; exe must be an absolute path to an existing file, and args is an array of strings.
• The reply carries pid, survivesSession, endsWithApp and inJob. endsWithApp is the measured answer: when it is false the reply also carries a note saying the program may outlive a crash, because it could not be placed in the app's cleanup job.
• Ordinary commands, dev servers and background runs need no change — they are meant to end with the session.
• A restart is the trap: starting an already-running program a second time from Bash moves the new copy into the session job, so restart through POST /programs/launch.
• Settings key: programLaunchEnabled. Feature switch: programLaunch.
• To hand a program back to Windows, add "handToWindows": true to the same request. It is refused 403 { optInRequired: true } until the person allows it, and the reply carries handedToWindows and survivesApp — both measured, not assumed. Settings keys: programHandoffToWindowsEnabled and programHandoffSessionGrant, neither of which an agent token can write.

Related

• Agent self-archive — what archiving a session actually does.
• Agent crews — sessions that report to a lead session.