LiuMangMang/agent-workflow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add web executor model configuration

Browse Source
This commit is contained in:
liujing
2026-07-20 16:59:24 +08:00
parent 4026f04b93
commit 64b3ef6c60
8 changed files with 1507 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/agent-workflow-host/SKILL.md
+1 -1
View File
@@ -115,7 +115,7 @@ Executor has been running for ~2m. Current activity: Editing src/parser.ts (PID
Start that `logs --follow` command at most once for a given Run in the current Codex thread. If it reports that a follower is already active, do not retry the same command; use `agent-workflow status --run <run-id> --json` for progress instead.
The `agent-workflow web` command starts a local read-only web server that reads workflow state files without taking follower locks or interrupting the main execution loop. It only binds to the local loopback interface (127.0.0.1) for safety, as logs can contain sensitive code and environment details. The web interface displays status, execution events, cycle summaries, and live log updates. The console displays the CLI's actual stdout/stderr outputs and parsed structured activity; it cannot reconstruct unlogged private model reasoning.
The `agent-workflow web` command starts a local web server that reads workflow state files without taking follower locks or interrupting the main execution loop. Workflow monitoring remains read-only: it displays status, execution events, cycle summaries, and live log updates, and cannot reconstruct unlogged private model reasoning. The console also exposes a Chinese global model settings view that can write only `executors.<kind>.model` overrides in `~/.agent-workflow/config.json`. Discovery uses each executor's current CLI environment, isolates failures per executor, never returns credentials, and always allows manual model entry. Project configuration can still override global values, and saved models take effect on later cycles/retries without restarting active executors. The server binds only to 127.0.0.1.
`timeoutSeconds` is a consecutive inactivity timeout. Observable executor output refreshes the deadline, so do not treat total runtime beyond that value as a timeout while activity continues.