| Files | Last commit | Last update |
|---|---|---|
Fix Windows CI - Keep mcp-tools.json line endings as LF so the snapshot test passes on Windows - Use std::env::home_dir so Windows respects USERPROFILE when finding the home directory | 6 days ago | |
Prefer snapshots over screenshots (#2453) * Prefer snapshots over screenshots in the core skill and chat prompt * Never screenshot to check for an element; wait and re-snapshot * Screenshot only when asked or for content the DOM cannot represent | 1 day ago | |
fix(daemon): keep security settings across daemon restarts (#2429) * fix(daemon): keep security settings across daemon restarts Allowed domains, action policy and confirm actions were lost with the daemon, so a restart silently dropped containment (#1894). They are now stored in an owner-only <session>.settings file before they apply, read back at daemon start, and removed by close. A file that cannot be used stops the daemon from starting. * docs: document persisted security settings * fix(daemon): harden stored security settings A CLI-driven daemon restart no longer clears the file, and close clears it only after the daemon confirmed the close, so a denied or parked close leaves the session contained. A relative action policy path is made absolute before it is stored. close --all also clears files of sessions whose daemon is gone. The boot refusal names the namespace and fits the stderr cap. The file is written with O_EXCL, read without following symlinks, and must belong to the daemon's user. * docs: describe when stored security settings are cleared * fix(daemon): close --all keeps settings of sessions that did not close close --all cleared the stored settings and reported success for a close that policy denied or that waited for confirmation. It now treats those as not closed. The legacy AGENT_BROWSER_POLICY path is stored absolute like the current variable, a ready daemon stores its security settings again so a racing sweep cannot leave it uncontained, and the boot hint quotes the session and namespace for the shell. * fix(cli): close keeps stored settings and policy paths stay valid UTF-8 close no longer deletes the stored settings before the daemon starts, so a policy that denies close still applies when the daemon was gone; the file is cleared only when the daemon refuses to start because of it. A policy path that is not valid UTF-8 after resolving is rejected instead of being stored lossy, and the path test no longer assumes forward slashes. * fix(cli): close --all closes sessions without a daemon under their stored policy close --all deleted the settings file of every session with no running daemon, so a policy that denies close was bypassed. Those sessions are now closed through the same path as close: a daemon starts with the stored settings, a denied or parked close keeps the file and is reported as failed, and a file the daemon refuses is cleared. * fix(cli): name the socket dir in the refusal hint and stop orphan daemons a failed close --all started * fix(cli): close clears an empty directory in place of the settings file and names an entry it cannot remove * test(cli): close --all leaves no daemon for a dead session it could not close * fix(cli): sync the settings directory after the rename and give the two-step way to confirm a parked close * fix(daemon): restore a stored empty allowed-domains list as no filter * test(daemon): a separator-only allowed-domains list leaves no filter | 2 days ago | |
feat: warn when Chrome is behind stable with later CVE fixes (#2309) * feat: refuse browsers that are behind stable before driving them Every command that drives a browser now passes one preflight gate before the action runs. The gate compares the connected build against the current stable release and refuses a build that is behind, listing the CVE ids the Chrome Releases feed documents as fixed after it. Advisories are cached for 24 hours in ~/.agent-browser/security-advisories.json, and the check fails open when no verdict can be fetched. Coverage comes from one adoption helper. Local launches, --cdp, and --auto-connect pass through it before pages are restored or init scripts run, and the command dispatcher gates browsers that an earlier command started. Provider sessions are skipped because the user cannot update them, and Lightpanda, Obscura, iOS, and Safari have no machine-readable advisory feed. close, dialog, confirm, and deny stay usable on a refused build. The override is --allow-outdated-browser or AGENT_BROWSER_ALLOW_OUTDATED_BROWSER. It is resolved per command in the daemon and stamped onto every outbound envelope by connection::send_command, so it applies to the command that asked for it and cannot latch a warm daemon into skipping the check. Docs, --help, both published schemas, skill-data, and the MCP extraArgs allowlist carry the flag and the current behavior. * fix: skip the launch envelope for commands that never open a browser With browser options set in the environment, the CLI sent a launch command before every invocation. close, state, auth, and session commands therefore started a browser only to tear it down, and once the version gate refused that launch, close failed too. action_is_browserless lists the commands that never touch a browser, and should_send_local_launch_config skips the envelope for them. * fix: check browser security before setup Compare Chrome against stable releases for its platform, and keep overrides and TLS trust scoped to each request. * fix: warn about outdated Chrome instead of refusing it The check now only warns. After a command that drives a browser, the daemon reads the Chrome version once per browser and compares it with the Stable Channel Update for Desktop posts on the Chrome Releases blog. If newer Stable releases fixed CVEs, the response carries a warning to update or run `agent-browser install`. The command always runs. Because nothing is refused, the opt-out flag, its env var, config key, schema and MCP parameter are gone, along with the recovery exemptions for close/dialog/confirm/deny, the pre-attach launch gates, the per-request TLS plumbing and the launch-warning merging in main.rs. Firefox, per-platform version lookups and the disk cache are dropped too. The feed fetch uses the process TLS options, a 3s timeout and a 4 MB cap, and fails silently. Tested with the full unit suite, clippy and the docs suites, and by running the CLI against Chrome for Testing 155.0.8059.84 (warning shown once) and 156.0.8078.80 (silent). * fix: add an opt-out for the browser version check - AGENT_BROWSER_NO_VERSION_CHECK=1 skips the check and its request to chromereleases.googleblog.com. Documented in --help, the configuration and security pages, and the core skill references. - Cap the per-command Browser.getVersion call at 3s, so a wedged browser can't hold a finished command for the 30s CDP timeout. - Drop the process TLS options from the feed fetch. The daemon never sets them, so the call did nothing; the docs now say the request uses the built-in root certificates. - Fix the docs, which listed a Firefox engine that doesn't exist. Checked against Chrome for Testing 155.0.8059.84: the warning shows by default and is gone with the env var set. | 5 days ago | |
feat(cli): trust private CAs in CLI HTTPS requests (#2006) * feat(cli): trust private CAs in CLI HTTPS requests read, install, upgrade and doctor verified peers against the compiled-in Mozilla roots only, so a proxy CA deployed by MDM, a sandbox or an enterprise image failed with UnknownIssuer. --ca-cert now adds a CA to these requests on every platform, --use-system-ca selects the OS trust store, and SSL_CERT_FILE is an ambient fallback. Verification stays on. read sends the resolved trust with each request, so the daemon holds no trust state. A command-line selection is saved beside the session until close and survives daemon restarts. --ca-cert on read no longer triggers a browser launch. Co-Authored-By: Bazyli Brzóska <563469+niieani@users.noreply.github.com> * fix(cli): keep the saved CA when a new one fails and trust batched reads * fix(cli): clear saved CA trust when a batch closes the session * test(docs): let the content floor accept inserted lines and declared edits The block-level floor rejected new table rows, new lines inside code blocks, and intentional rewrites of original text, so any docs correction failed. Compare original lines in order instead, and apply rewrites declared in fixtures/docs-edits.json to the live floor. The pinned baseline is unchanged. --------- Co-authored-by: Bazyli Brzóska <563469+niieani@users.noreply.github.com> | 1 month ago | |
fix(dashboard): keep chat commands in the thread's own session (#2190) * fix(dashboard): keep chat commands in the thread's own session The dashboard chat ran model tool calls with any --session the model added. Models invent a new session name per task, so work landed in a different browser than the one open in the dashboard. Dashboard chat now drops a model-supplied --session and always uses the chat's own session. The interactive CLI chat keeps today's behavior. Added a unit test for both modes. * fix(chat): bind chat to its session and keep threads with their session - The prompt and tool description no longer offer --session or --engine, and the prompt names the chat's session. chat_command_args runs the args through the CLI flag parser and rejects a different session instead of silently dropping it. - Chat stops instead of relaunching a session that was closed mid-turn, and the dashboard chat handler stops before the next command once the client disconnects. - The dashboard keeps one chat per session across switches, saves a background turn when it finishes, and stops and clears a session's chat when the session closes. Threads live in localStorage but the old cleanup cleared sessionStorage. Tested with cargo test chat, the dashboard build, and live dashboard runs on claude-sonnet-4.6, gpt-5.5 and gpt-5.6-sol: switching mid-stream, closing from the dashboard, CLI and Close all, and recreating a session under the same name. * fix(chat): validate chat flags without parsing them in the dashboard The session check called parse_flags inside the dashboard process. parse_flags loads --config and exits the process when that fails, so a model command with a bad --config could shut down the dashboard. Chat now checks the model's words with clean_args, which has no side effects, and rejects any global flag other than --json and --annotate. This also blocks --namespace, which could start a browser outside the chat's session, along with flags like --allow-file-access and --cdp. Tested with cargo test chat (the test includes --config /nonexistent, so an in-process parse would exit the test run) and a live dashboard run where --config /nonexistent and --namespace other both came back Blocked and the dashboard stayed up. | 16 days ago | |
Add AI chat to dashboard, refactor stream module, snapshot --urls, batch argument mode (#1160) * chat * refactor * fixes * fixes * fixes * fixes * improvements * download chat * batch * fixes * fixes * fixes * fmt * fixes * fixes * fixes * fmt | 6 months ago | |
fix(flow): wait for in-flight requests on save and finalize redirect hops (#2433) * fix(flow): wait for in-flight requests before saving flow save cloned the recorded entries right after one drain, so a request the last step had started but not finished had no response body and was dropped. The save now drains until requests tagged to the saved steps finish, bounded by the command timeout. * fix(flow): do not wait on third-party or streaming requests when saving The save waits only for unfinished requests that could become flow requests: first-party, not telemetry, XHR/Fetch with a JSON (or not yet known) type, or a document. Event streams and other non-JSON responses never delay it. * fix(flow): bound the save wait by redirects, the client read timeout, and report what is left out A redirect hop never finishes, so it no longer counts as an unfinished request. flow_save carries the default timeout like the wait commands, so the client read timeout follows it. Requests still loading at the deadline are reported as gaps. * fix(har): finalize a redirect hop when the redirect is followed Network.requestWillBeSent with redirectResponse now fills the previous entry for that request id (status, headers, mime type) and stamps its finish time, so the hop no longer stays incomplete in har stop and network requests. The flow save wait no longer needs a special case for it. * fix(test): box the command future at execute_command The debug-build command future is large enough to overflow a test thread's stack when a test awaits it directly; it now lives on the heap for every caller. * fix(flow): redact and scope still-loading gaps, finalize redirect hops in network requests * fix(flow): keep secret and login gaps, detect undecodable secrets, return the final redirect hop A step with a loading request only loses its generic no-request reason, not the secret-drop or login-wall gaps. Secret detection decodes percent escapes that are not valid UTF-8 instead of skipping the comparison. network request returns the last hop that shares a request id. The har_compute_timings doc comment is back on its function. * fix(flow): decode every escape leniently when looking for a secret The form-encoded comparison and the dropped-request label use the lossless decode too, and an undecodable escape is kept exactly as written, so a lowercase escape in a secret still matches. * fix(flow): flow save does not wait on a long poll, and names requests still loading when it fails A first-party JSON request whose headers came and whose body never ended kept every save waiting for the whole command timeout. A response with headers that gets no bytes for the network idle window is no longer waited on and is reported as still loading. A save that failed for want of requests returned before the still-loading gaps were added, so the error hid the request that explained it. The error now names them. * fix(flow): flow save waits on a request with no answer only if the last step started it A request a long-poll server holds without writing headers kept every save waiting for the whole command timeout. A request with no response that an earlier step started has outlived the steps after it, so it is reported as still loading instead of waited on. One the last step started is still awaited up to the command timeout. * fix(flow): flow save reads --timeout The save path never read the flag, so a request the last step left hanging still blocked for the default timeout. The CLI and the MCP tool now pass it. | 2 days ago | |
fix(daemon): keep security settings across daemon restarts (#2429) * fix(daemon): keep security settings across daemon restarts Allowed domains, action policy and confirm actions were lost with the daemon, so a restart silently dropped containment (#1894). They are now stored in an owner-only <session>.settings file before they apply, read back at daemon start, and removed by close. A file that cannot be used stops the daemon from starting. * docs: document persisted security settings * fix(daemon): harden stored security settings A CLI-driven daemon restart no longer clears the file, and close clears it only after the daemon confirmed the close, so a denied or parked close leaves the session contained. A relative action policy path is made absolute before it is stored. close --all also clears files of sessions whose daemon is gone. The boot refusal names the namespace and fits the stderr cap. The file is written with O_EXCL, read without following symlinks, and must belong to the daemon's user. * docs: describe when stored security settings are cleared * fix(daemon): close --all keeps settings of sessions that did not close close --all cleared the stored settings and reported success for a close that policy denied or that waited for confirmation. It now treats those as not closed. The legacy AGENT_BROWSER_POLICY path is stored absolute like the current variable, a ready daemon stores its security settings again so a racing sweep cannot leave it uncontained, and the boot hint quotes the session and namespace for the shell. * fix(cli): close keeps stored settings and policy paths stay valid UTF-8 close no longer deletes the stored settings before the daemon starts, so a policy that denies close still applies when the daemon was gone; the file is cleared only when the daemon refuses to start because of it. A policy path that is not valid UTF-8 after resolving is rejected instead of being stored lossy, and the path test no longer assumes forward slashes. * fix(cli): close --all closes sessions without a daemon under their stored policy close --all deleted the settings file of every session with no running daemon, so a policy that denies close was bypassed. Those sessions are now closed through the same path as close: a daemon starts with the stored settings, a denied or parked close keeps the file and is reported as failed, and a file the daemon refuses is cleared. * fix(cli): name the socket dir in the refusal hint and stop orphan daemons a failed close --all started * fix(cli): close clears an empty directory in place of the settings file and names an entry it cannot remove * test(cli): close --all leaves no daemon for a dead session it could not close * fix(cli): sync the settings directory after the rename and give the two-step way to confirm a parked close * fix(daemon): restore a stored empty allowed-domains list as no filter * test(daemon): a separator-only allowed-domains list leaves no filter | 2 days ago | |
fix(daemon): keep security settings across daemon restarts (#2429) * fix(daemon): keep security settings across daemon restarts Allowed domains, action policy and confirm actions were lost with the daemon, so a restart silently dropped containment (#1894). They are now stored in an owner-only <session>.settings file before they apply, read back at daemon start, and removed by close. A file that cannot be used stops the daemon from starting. * docs: document persisted security settings * fix(daemon): harden stored security settings A CLI-driven daemon restart no longer clears the file, and close clears it only after the daemon confirmed the close, so a denied or parked close leaves the session contained. A relative action policy path is made absolute before it is stored. close --all also clears files of sessions whose daemon is gone. The boot refusal names the namespace and fits the stderr cap. The file is written with O_EXCL, read without following symlinks, and must belong to the daemon's user. * docs: describe when stored security settings are cleared * fix(daemon): close --all keeps settings of sessions that did not close close --all cleared the stored settings and reported success for a close that policy denied or that waited for confirmation. It now treats those as not closed. The legacy AGENT_BROWSER_POLICY path is stored absolute like the current variable, a ready daemon stores its security settings again so a racing sweep cannot leave it uncontained, and the boot hint quotes the session and namespace for the shell. * fix(cli): close keeps stored settings and policy paths stay valid UTF-8 close no longer deletes the stored settings before the daemon starts, so a policy that denies close still applies when the daemon was gone; the file is cleared only when the daemon refuses to start because of it. A policy path that is not valid UTF-8 after resolving is rejected instead of being stored lossy, and the path test no longer assumes forward slashes. * fix(cli): close --all closes sessions without a daemon under their stored policy close --all deleted the settings file of every session with no running daemon, so a policy that denies close was bypassed. Those sessions are now closed through the same path as close: a daemon starts with the stored settings, a denied or parked close keeps the file and is reported as failed, and a file the daemon refuses is cleared. * fix(cli): name the socket dir in the refusal hint and stop orphan daemons a failed close --all started * fix(cli): close clears an empty directory in place of the settings file and names an entry it cannot remove * test(cli): close --all leaves no daemon for a dead session it could not close * fix(cli): sync the settings directory after the rename and give the two-step way to confirm a parked close * fix(daemon): restore a stored empty allowed-domains list as no filter * test(daemon): a separator-only allowed-domains list leaves no filter | 2 days ago | |
Fix Windows CI - Keep mcp-tools.json line endings as LF so the snapshot test passes on Windows - Use std::env::home_dir so Windows respects USERPROFILE when finding the home directory | 6 days ago | |
fix(daemon): keep security settings across daemon restarts (#2429) * fix(daemon): keep security settings across daemon restarts Allowed domains, action policy and confirm actions were lost with the daemon, so a restart silently dropped containment (#1894). They are now stored in an owner-only <session>.settings file before they apply, read back at daemon start, and removed by close. A file that cannot be used stops the daemon from starting. * docs: document persisted security settings * fix(daemon): harden stored security settings A CLI-driven daemon restart no longer clears the file, and close clears it only after the daemon confirmed the close, so a denied or parked close leaves the session contained. A relative action policy path is made absolute before it is stored. close --all also clears files of sessions whose daemon is gone. The boot refusal names the namespace and fits the stderr cap. The file is written with O_EXCL, read without following symlinks, and must belong to the daemon's user. * docs: describe when stored security settings are cleared * fix(daemon): close --all keeps settings of sessions that did not close close --all cleared the stored settings and reported success for a close that policy denied or that waited for confirmation. It now treats those as not closed. The legacy AGENT_BROWSER_POLICY path is stored absolute like the current variable, a ready daemon stores its security settings again so a racing sweep cannot leave it uncontained, and the boot hint quotes the session and namespace for the shell. * fix(cli): close keeps stored settings and policy paths stay valid UTF-8 close no longer deletes the stored settings before the daemon starts, so a policy that denies close still applies when the daemon was gone; the file is cleared only when the daemon refuses to start because of it. A policy path that is not valid UTF-8 after resolving is rejected instead of being stored lossy, and the path test no longer assumes forward slashes. * fix(cli): close --all closes sessions without a daemon under their stored policy close --all deleted the settings file of every session with no running daemon, so a policy that denies close was bypassed. Those sessions are now closed through the same path as close: a daemon starts with the stored settings, a denied or parked close keeps the file and is reported as failed, and a file the daemon refuses is cleared. * fix(cli): name the socket dir in the refusal hint and stop orphan daemons a failed close --all started * fix(cli): close clears an empty directory in place of the settings file and names an entry it cannot remove * test(cli): close --all leaves no daemon for a dead session it could not close * fix(cli): sync the settings directory after the rename and give the two-step way to confirm a parked close * fix(daemon): restore a stored empty allowed-domains list as no filter * test(daemon): a separator-only allowed-domains list leaves no filter | 2 days ago | |
docs(flow): mark saved flows experimental in the skill and MCP tools (#2444) The CLI help and the network docs already call saved flows experimental, but the agent-facing surfaces did not. A run can fail on a page that changed or answers differently each time, so the core skill, the commands reference and the four flow MCP tools now say so and point back to the UI. | 2 days ago | |
fix(flow): send run requests only to public addresses (#2432) * fix(flow): send run requests only to public addresses * fix(flow): do not filter proxy hosts from the environment * fix(flow): refuse proxy hosts as targets and close classifier gaps * fix(flow): build proxies explicitly, honor NO_PROXY, drop name-based exemption * fix(flow): read proxy env like hyper-util and resolve proxy names asynchronously * fix(flow): an unreachable proxy fails only the requests that would use it A proxy name that did not resolve aborted every run, even for targets NO_PROXY sends direct. The proxy now keeps its name and the resolver refuses it with the lookup error, so only requests routed through it fail. * fix(flow): a flow recorded against a name that resolves locally keeps running The resolver refused every name that resolved to a non-public address, so flows recorded against lvh.me, .test or intranet hosts stopped working. flow save now records reach local when the browser reached the start host directly at non-public addresses, on the URL's port, that the name still resolves to; a run of that flow admits only local addresses. A recording through any proxy reports the proxy's port, so it never counts as local. * fix(flow): look up an http proxy only when a request uses it, and name reach in local refusals Every http:// proxy name was resolved before the first request, so a stale or off-VPN proxy stalled each run up to the lookup timeout even when NO_PROXY excluded every target. The proxy URL now carries a stand-in name, unique to the run, that the resolver maps back to the real name when a connection to the proxy is made. A flow file without a recorded reach that hits a local address now says to record it again so the file gets "reach": "local". * fix(flow): say why a flow recorded through a proxy is not marked local A recording through a proxy stores the proxy's address, so flow save records no reach, and the run's advice to save again produced the same file. The save report now carries reachNote naming the addresses seen and asking for a direct recording, and the run's refusal says the same. * fix(flow): show reachNote in flow save text output The default CLI output and MCP text dropped reachNote, hiding why a flow recorded through a proxy cannot run directly. * fix(flow): a local flow never reaches link-local or metadata addresses, and a loopback recording stays on loopback Reach::Local admitted every non-public address, so a flow saved as local for a name that once resolved to loopback followed that name to 169.254.169.254. A recording whose addresses are all loopback now saves reach loopback, localhost flows are loopback-only, and a local reach refuses link-local and cloud metadata addresses. The save note was produced only when both the recorded and the resolved addresses were non-public, so a recording with no start-host address or a proxy at a public address got no reach and no note. Any start host that resolves only to local addresses without a matching direct connection now gets the note. * fix(flow): refuse a link-local or metadata IP literal before sending IP-literal hosts skip the resolver, so a flow whose start URL was a link-local literal still sent to 169.254.x. The host check now refuses link-local and cloud metadata literals for every request and redirect. | 2 days ago | |
Fix Windows CI - Keep mcp-tools.json line endings as LF so the snapshot test passes on Windows - Use std::env::home_dir so Windows respects USERPROFILE when finding the home directory | 6 days ago | |
feat(cli): trust private CAs in CLI HTTPS requests (#2006) * feat(cli): trust private CAs in CLI HTTPS requests read, install, upgrade and doctor verified peers against the compiled-in Mozilla roots only, so a proxy CA deployed by MDM, a sandbox or an enterprise image failed with UnknownIssuer. --ca-cert now adds a CA to these requests on every platform, --use-system-ca selects the OS trust store, and SSL_CERT_FILE is an ambient fallback. Verification stays on. read sends the resolved trust with each request, so the daemon holds no trust state. A command-line selection is saved beside the session until close and survives daemon restarts. --ca-cert on read no longer triggers a browser launch. Co-Authored-By: Bazyli Brzóska <563469+niieani@users.noreply.github.com> * fix(cli): keep the saved CA when a new one fails and trust batched reads * fix(cli): clear saved CA trust when a batch closes the session * test(docs): let the content floor accept inserted lines and declared edits The block-level floor rejected new table rows, new lines inside code blocks, and intentional rewrites of original text, so any docs correction failed. Compare original lines in order instead, and apply rewrites declared in fixtures/docs-edits.json to the live floor. The pinned baseline is unchanged. --------- Co-authored-by: Bazyli Brzóska <563469+niieani@users.noreply.github.com> | 1 month ago | |
fix(daemon): keep security settings across daemon restarts (#2429) * fix(daemon): keep security settings across daemon restarts Allowed domains, action policy and confirm actions were lost with the daemon, so a restart silently dropped containment (#1894). They are now stored in an owner-only <session>.settings file before they apply, read back at daemon start, and removed by close. A file that cannot be used stops the daemon from starting. * docs: document persisted security settings * fix(daemon): harden stored security settings A CLI-driven daemon restart no longer clears the file, and close clears it only after the daemon confirmed the close, so a denied or parked close leaves the session contained. A relative action policy path is made absolute before it is stored. close --all also clears files of sessions whose daemon is gone. The boot refusal names the namespace and fits the stderr cap. The file is written with O_EXCL, read without following symlinks, and must belong to the daemon's user. * docs: describe when stored security settings are cleared * fix(daemon): close --all keeps settings of sessions that did not close close --all cleared the stored settings and reported success for a close that policy denied or that waited for confirmation. It now treats those as not closed. The legacy AGENT_BROWSER_POLICY path is stored absolute like the current variable, a ready daemon stores its security settings again so a racing sweep cannot leave it uncontained, and the boot hint quotes the session and namespace for the shell. * fix(cli): close keeps stored settings and policy paths stay valid UTF-8 close no longer deletes the stored settings before the daemon starts, so a policy that denies close still applies when the daemon was gone; the file is cleared only when the daemon refuses to start because of it. A policy path that is not valid UTF-8 after resolving is rejected instead of being stored lossy, and the path test no longer assumes forward slashes. * fix(cli): close --all closes sessions without a daemon under their stored policy close --all deleted the settings file of every session with no running daemon, so a policy that denies close was bypassed. Those sessions are now closed through the same path as close: a daemon starts with the stored settings, a denied or parked close keeps the file and is reported as failed, and a file the daemon refuses is cleared. * fix(cli): name the socket dir in the refusal hint and stop orphan daemons a failed close --all started * fix(cli): close clears an empty directory in place of the settings file and names an entry it cannot remove * test(cli): close --all leaves no daemon for a dead session it could not close * fix(cli): sync the settings directory after the rename and give the two-step way to confirm a parked close * fix(daemon): restore a stored empty allowed-domains list as no filter * test(daemon): a separator-only allowed-domains list leaves no filter | 2 days ago | |
feat(skills): load one reference with skills get --ref (#2310) * feat(skills): load one reference with skills get --ref skills get returned SKILL.md alone or every reference with --full. --ref <ref> returns only the named reference or template, matched by path, file name, or stem, and the MCP skills_get tool takes the same values in refs. The core guide's routing table now loads references this way instead of reading the skill directory. * test(evals): check that agents load one reference with skills get --ref reference-routing gives the model the core guide as already loaded and asks for tasks that need one reference. It passes when the model loads that reference with --ref, and fails on --full or reading the skill directory. A control case checks that a task core covers loads no reference. | 5 days ago | |
fix: restore release CI (#1862) * fix: restore release CI - Accept Windows shutdown semantics and platform-native test paths. - Preserve CDP navigation events across stream session rebinds. - Harden E2E readiness and test environment recovery. * fix: prevent stale frames across stream rebinds - Preserve navigation and runtime events while discarding stale screencast frames during restarts. - Scope frame delivery to the currently bound CDP session. - Cover session and viewport rebind races with regression tests. * fix: invalidate stale stream frames - Clear cached frames when CDP sessions or viewport dimensions change. - Revalidate in-flight frames before publishing after acknowledgements. - Cover rebinds with cached-frame regression tests. | 1 month ago | |
fix(windows): pass the Rust suite on Windows (#2223) * fix(windows): treat exited processes as dead and fix the CA path test OpenProcess succeeds for an exited process while any handle to it is open, so is_pid_alive also checks GetExitCodeProcess. The CA selection test now uses a platform absolute path instead of a Unix one. * test(obscura): keep the Windows runtime environment in CLI tests * fix(windows): connect only to the port this session's daemon wrote The hash-derived port ignores the socket directory, so before the daemon writes its .port file the client could reach another daemon with the same session name. | 13 days ago | |
feat(cli): trust private CAs in CLI HTTPS requests (#2006) * feat(cli): trust private CAs in CLI HTTPS requests read, install, upgrade and doctor verified peers against the compiled-in Mozilla roots only, so a proxy CA deployed by MDM, a sandbox or an enterprise image failed with UnknownIssuer. --ca-cert now adds a CA to these requests on every platform, --use-system-ca selects the OS trust store, and SSL_CERT_FILE is an ambient fallback. Verification stays on. read sends the resolved trust with each request, so the daemon holds no trust state. A command-line selection is saved beside the session until close and survives daemon restarts. --ca-cert on read no longer triggers a browser launch. Co-Authored-By: Bazyli Brzóska <563469+niieani@users.noreply.github.com> * fix(cli): keep the saved CA when a new one fails and trust batched reads * fix(cli): clear saved CA trust when a batch closes the session * test(docs): let the content floor accept inserted lines and declared edits The block-level floor rejected new table rows, new lines inside code blocks, and intentional rewrites of original text, so any docs correction failed. Compare original lines in order instead, and apply rewrites declared in fixtures/docs-edits.json to the live floor. The pinned baseline is unchanged. --------- Co-authored-by: Bazyli Brzóska <563469+niieani@users.noreply.github.com> | 1 month ago | |
fix: validate session names before use (#2272) * fix: validate session names before execution Co-Authored-By: Vishnu Jayavel <vishnuj81093@gmail.com> Co-Authored-By: Dwin Gharibi <dwin.gharibi@email.kntu.ac.ir> * docs: document session name rules * style: format session validation regression test * fix: validate sessions only for session commands * fix(mcp): return config errors without exiting Keep the exiting CLI wrapper and use fallible flag parsing for MCP. Cover selected configs removed or corrupted after initialization, and keep config fixtures aligned with explicit trust. --------- Co-authored-by: Vishnu Jayavel <vishnuj81093@gmail.com> Co-authored-by: Dwin Gharibi <dwin.gharibi@email.kntu.ac.ir> | 8 days ago |
| Files | Last commit | Last update |
|---|---|---|
| 6 days ago | ||
| 1 day ago | ||
| 2 days ago | ||
| 5 days ago | ||
| 1 month ago | ||
| 16 days ago | ||
| 6 months ago | ||
| 2 days ago | ||
| 2 days ago | ||
| 2 days ago | ||
| 6 days ago | ||
| 2 days ago | ||
| 2 days ago | ||
| 2 days ago | ||
| 6 days ago | ||
| 1 month ago | ||
| 2 days ago | ||
| 5 days ago | ||
| 1 month ago | ||
| 13 days ago | ||
| 1 month ago | ||
| 8 days ago |