Windows integration and permissions

Screph works with the screen, global keys and several input backends. This page separates ordinary application behavior from actions that modify Windows or an external device.

1. What the installer does

The current Qt Installer Framework configuration proposes %LOCALAPPDATA%\Screph. It creates a Screph Start menu shortcut; the desktop shortcut is created only when the user selects its separate option, which is off by default. The installation also places the uninstall.exe maintenance tool, component metadata and ScrephData beside the application.

During reinstall, the wizard preserves projects, settings, models and local dependencies in ScrephData by default. During uninstall, the user-data removal checkbox is not selected by default. Windows Credential Manager secrets and project-local data outside the installation directory require separate review; see Local data and secrets.

2. When UAC appears

Ordinary settings, markup, CV and project saving run with the current user's permissions. Screph explicitly requests elevation through Windows runas when installing FakerInput Virtual HID. The installer or maintenance tool may also request elevation when the chosen directory or operation requires it; that is an installer-context decision rather than hidden elevation of a project.

UAC does not turn Automation Runtime into a sandbox. After backend installation, workflows still run with the ordinary Screph process permissions and can generate input.

3. FakerInput Virtual HID

Selecting FakerInput for the first time immediately starts backend preparation. Before elevation, Screph validates the bundled MSI's exact SHA256, valid Authenticode signature and expected signer. It then uses one UAC request to run msiexec /i … /qn /norestart, installing a system Virtual HID keyboard and mouse driver.

  • Cancelling UAC or failing validation restores the previous mode and shows an error.
  • MSI codes 1641/3010 or an unready device stack mean that a manual Windows restart may be required; Screph does not restart the system itself.
  • The driver is system-wide rather than project-scoped. Remove it through the installed package or Windows facilities when the backend is no longer needed.

4. Arduino Leonardo firmware

The Flash Arduino button is not a connection test. Screph moves a compatible Leonardo/ATmega32U4 into its bootloader (through an HID command or a 1200-baud sketch-port reset), waits up to ten seconds for the new COM port and runs the selected avrdude.exe to write the selected .hex to flash.

Flashing changes the board's behavior and USB identity. Use firmware matching the selected HID or legacy profile, and close Arduino IDE or other programs holding the COM port. Failure or interruption may require entering the bootloader again and recovering the firmware. The operation does not itself require UAC, but it modifies an external device.

5. Windows mouse settings

The Arduino-compatible runtime reads pointer speed, acceleration, thresholds, Snap To, trails and swapped buttons to diagnose inaccurate relative HID movement. Normal runtime behavior only reads these settings and warns about risk.

The separate --apply-recommended CLI command explicitly modifies the current user's profile: it sets speed to 10, disables acceleration/thresholds and Snap To, persists the settings and broadcasts the system change. Screph does not run this command silently or automatically restore previous values, so record them first.

6. Global hotkeys and hooks

The tray process registers global combinations through the keyboard library: capture Ctrl+Alt+S, settings F2, record/pause Ctrl+Alt+R and alternate pause Ctrl+Alt+P. They do not suppress normal key processing; a conflict with another application may cause failure or duplicate behavior. Registrations are removed during normal tray shutdown.

The capture-hotkey field in the main Settings window stores tray.hotkey, but the current tray neither reads it at startup nor receives a live update. The separate hotkey dialog in the tray menu changes the combination for the current process but does not persist it for the next launch.

Action-sequence capture installs low-level Windows mouse and keyboard hooks only while recording user actions. This is local input observation for the Action Trace and does not itself upload events to the network.

7. Tray settings, autostart and firewall

Current boundary: of the four fields on the Tray Settings page, the runtime consumes only Close the application when the window closes. tray.autostart, tray.hotkey and tray.save_dir are stored but not read by the current tray. It creates no Windows Run entry, Startup shortcut or Scheduled Task, starts with capture hotkey Ctrl+Alt+S, and passes its own ScrephData/automation_runtime/project/autosave directory to Selector.

The ordinary desktop runtime and current QtIFW package script also contain no Windows Firewall rule creation. Local loopback listeners are documented in the architecture guide; the presence of a listener does not mean Screph added a firewall exception.

8. Updates and process shutdown

The automatic startup check only fetches Updates.xml metadata. Installation begins after user confirmation. Screph checks for an unsaved Selector project, stops recording, saves settings and attempts to close Screph Code; it then closes windows and schedules the separate maintenance tool about two seconds later.

Screph launches the maintenance tool without its own runas; Windows or the installer may request elevation depending on the installation and selected operation. Refusing UAC or closing the maintenance tool leaves the update incomplete and does not cause Screph to bypass permissions.

Automation Runtime Local data