For the complete documentation index, see llms.txt. This page is also available as Markdown.

Agent Runtime & Update Reference

Reference for the desktop agent's runtime components, log and data locations, the auto-update system, and local commands IT admins can run to inspect or troubleshoot updates on a machine.

This page is a machine-level reference for the desktop agent: which processes run, where they log, how auto-update works end to end, and the commands you can run locally to verify all of it. It is primarily written for Windows Standard installs, with Stealth and macOS notes where they differ.

If you are diagnosing a broken agent rather than inspecting a healthy one, start with Desktop Doctor and the Tracker Failure Diagnostic Guide.


Runtime components

Windows — Standard

Install directory: C:\Program Files\Zenstack\MyZenV2

Component
Path
Role

MyZenV2.exe

C:\Program Files\Zenstack\MyZenV2\MyZenV2.exe

Main tray application (tracking, screenshots, punch in/out UI). Runs per logged-in user.

zen_cli.exe

C:\Program Files\Zenstack\MyZenV2\zen_cli.exe

Command-line helper used for install-time checks and diagnostics.

install_notifier.exe

C:\Program Files\Zenstack\MyZenV2\install_notifier.exe

Notifies logged-in users after an update installs.

ffmpeg.exe

C:\Program Files\Zenstack\MyZenV2\ffmpeg.exe

Screen-recording encoder, launched on demand by the main app.

version.txt

C:\Program Files\Zenstack\MyZenV2\version.txt

The locally installed version.

Windows Standard has no on-machine auto-updater today — there is no resident updater process and no scheduled task. Machines are updated by deploying the new MSI through your normal software-distribution channel (Intune, GPO, SCCM, or a manual reinstall); the MSI upgrades in place and preserves configuration. A native auto-updater (mirroring the macOS launchd updater) is planned for an upcoming release. macOS Standard and Stealth (both platforms) do auto-update — see below.

Windows — Stealth

Install directory: C:\Program Files\zs. The supervisors live outside the install directory:

Component
Path
Role

svcmonitor.exe

C:\Windows\svcmonitor.exe

Windows service / watchdog. Runs the update check loop inline (there is no separate updater task for stealth), supervises the agent, and applies domain blocking.

svcrunner.exe

C:\Windows\svcrunner.exe

Secondary watchdog that keeps svcmonitor and the agent alive.

MyZenV2.exe (agent)

under C:\Program Files\zs

The tracking agent, run headless per user session.

macOS — Standard

Component
Path

Main app

/Applications/MyZenV2.app

Installed version

/Applications/MyZenV2.app/Contents/MacOS/version.txt

Updater

updater binary inside the app bundle, scheduled by the standard-updater launchd plist (same 12-hour cadence).


Log and data locations (Windows)

What
Location

Main app logs (Standard)

%APPDATA%\ai.we360\MyZen\logs\log_YYYY-MM-DD.log

Local activity database (Standard)

%APPDATA%\ai.we360\MyZen\zs.db

App configuration (Standard)

%APPDATA%\ai.we360\MyZen.ini

Go helper / updater logs

zen-<component>-YYYY-MM-DD.log in the process's temp directory — %TEMP% for per-user processes, C:\Windows\Temp (or C:\ProgramData\Temp if that is not writable) for SYSTEM processes such as zs_manager.exe and svcmonitor.exe. Example: C:\Windows\Temp\zen-zs_manager-2026-07-14.log.

Stealth service logs

C:\Windows\Temp\zen-svcmonitor-YYYY-MM-DD.log — each service start logs one grep-friendly Updater diagnostics: line containing the resolved installer URL, remote version, and installed version.

Enable verbose debug logging: create an empty file named .zs-debug in %TEMP% or in the user's home directory. On the next start, the Go components switch to debug-level logging and force file logging on. Delete the file to return to normal.

On macOS, the equivalent app data directory is ~/Library/Application Support/ai.we360/MyZen/ (logs in logs/, database zs.db), and Go component logs go to the system temp directory with the same zen-<component>-<date>.log naming.


How auto-update works

Auto-update currently applies to macOS Standard (the launchd-scheduled updater binary inside the app bundle) and Stealth (the update loop inside svcmonitor). Windows Standard is updated by redeploying the MSI — see the commands below. Every auto-update run walks the same pipeline:

  1. Resolve the tenant from the local configuration.

  2. Auto-update policy gate. The updater asks the We360 origin server whether this device/tenant allows auto-update:

    • A device-level setting (per machine) is checked first, then the tenant manifest's auto-update flag.

    • If no tenant is configured yet (fresh install), updates are allowed so unconfigured machines don't strand on stale builds.

    • If a tenant is configured but the policy cannot be fetched, updates are skipped — the updater never installs without an authoritative "yes".

  3. Resolve the installer URL. Server-first: GET /discover/v1/tenant/{id}/update-urls/ on the origin server returns the per-tenant installer URLs by brand / OS / architecture / asset type. If the endpoint is unreachable or has no matching asset, the updater falls back to the CDN base URL baked into the binary at build time plus the canonical filename (MyZenV2.msi on Windows, MyZenV2-<arch>.pkg on macOS).

  4. Fetch the version manifest. Every published installer has a JSON sidecar at <installer-url>.version containing version, build_version, commit, built_at, md5, brand, OS, and arch. Any network error, non-2xx response, or implausible version string skips the tick — the updater never installs from a junk response.

  5. Version gate. The update proceeds only when the remote version is strictly newer than the local version.txt (semver comparison). This blocks accidental downgrades; a rollback requires publishing a higher-versioned build.

  6. Download, verify, install. The installer is downloaded, its MD5 is verified against the manifest, and it is installed silently (SYSTEM context on Windows, so no UAC prompt). Users are then notified via install_notifier.

Local override markers

Three sentinel files under C:\ProgramData (or /tmp and /etc on Unix) let you veto updates on a specific machine — useful for pinning a machine during troubleshooting or QA:

File
Effect

C:\ProgramData\zs-do-not-update

Skip all update installs on this machine.

C:\ProgramData\zs-dev-mode

Same skip, intended for development machines.

C:\ProgramData\zs-updater-abort

Aborts an in-flight update.

Create them as empty files; delete them to re-enable updates.


Local commands — checking the update system on a machine

All commands below are for Windows Standard, run from an elevated PowerShell or Command Prompt unless noted.

1. What version is installed?

2. What version is published?

Fetch the .version sidecar next to the published installer:

You should get a small JSON document with version, md5, built_at, etc. If you get HTML instead, the URL is wrong or being intercepted by a proxy — see Network & Security Hardening. Tenants with a custom installer base URL should substitute their own base path.

3. Update the machine

Download the current MSI (see Download Links & Utilities) and install it over the existing version — it upgrades in place and preserves configuration:

For fleet-wide updates use your normal channel: Intune, GPO, or command line.

4. Stealth machines

Stealth has no standalone updater or scheduled task — svcmonitor.exe runs the same pipeline internally. To check it, grep the service log for the diagnostics line:

The line includes effective_base_url, installer_url, installed_version, remote_version, and is_remote_newer — a complete snapshot of what the updater would do on its next tick.


zs_manager — online installer utility (Windows)

zs_manager.exe is a web-installer wrapper: a small self-contained utility that resolves the correct installer for the machine's tenant, downloads it, and runs it silently. It is a support/IT tool — it is not part of the agent install, not a resident process, and not the mechanism by which deployed agents update. It is still work in progress, so treat its behavior as subject to change.

The same binary also powers the renamed standalone web installers (e.g. myzen-standalone.exe for a standard install, or a stealth installer named after the license key) — those are distributed separately and behave as one-shot online installers; the zs_manager.exe download here is the raw utility with the mode switches below.

Download: zs_manager.exe (also listed on Download Links & Utilities).

Run it elevated. Modes:

Command
What it does

zs_manager.exe /updater-standard

Install/repair the Standard agent: checks the tenant's auto-update policy, resolves the installer URL, downloads, installs silently. Add /patch-only to refuse a full reinstall when the existing installation looks valid.

zs_manager.exe /updater-stealth

Same flow for the Stealth agent (requires an onboarded machine with a valid key configuration).

... --dry-run

Append to either mode to print a [DRY-RUN] report without changing the machine: system info, the live update context from the origin server (AutoUpdateEnabled, InstallerBaseUrl), and the exact installer URL a real run would download. This is the quickest way to check what the update system sees for a given machine/tenant.

Logs go to zen-zs_manager-YYYY-MM-DD.log in the temp directory (C:\Windows\Temp when run elevated).

For testing, the WE360_INSTALL_BASE_URL environment variable overrides the built-in CDN fallback URL so the flow can be pointed at a staging or local HTTP server serving MyZenV2.msi + MyZenV2.msi.version. Per-tenant URLs returned by the origin server still take precedence over the override.


macOS quick reference

Task
Command

Installed version

cat /Applications/MyZenV2.app/Contents/MacOS/version.txt

Updater config

/Applications/MyZenV2.app/Contents/MacOS/updater --show-config

Dry-run

sudo /Applications/MyZenV2.app/Contents/MacOS/updater --dry-run

Update schedule

launchctl print system | grep -i updater (loaded from the standard-updater plist)

Skip markers

/tmp/zs-do-not-update, /etc/zs-dev-mode

Last updated

Was this helpful?