DEV Community: David Díaz

Pinky Routes AI Phone Control Through a User Approval Gateway

David Díaz — Thu, 12 Nov 2026 20:39:43 +0000

Pinky is available as a public, Apache-2.0-licensed pre-alpha gateway that lets MCP-capable agents operate supported Android phones and iPhones while the owner watches, approves risky actions or takes control. For developers, the immediate consequence is that agents including Claude Code, Claude Desktop, Codex and Cursor can reach mobile interfaces from macOS, Windows or Linux, with agent connections available over stdio or HTTP. The project describes the gateway, supported agents and desktop platforms in its repository.

Gateway-enforced approvals

Payments, trades and transfers require approval by default. Users can also require confirmation for sends, orders, deletions, calls, installations, links that leave an app, settings changes or every step. Pinky says these rules run in its gateway rather than in instructions given to the agent, preventing an agent from approving its own action; the project claims to identify relevant buttons in 10 languages. Pinky documents these approval categories and their enforcement model on its project page.

The gateway also hides banking, wallet and password-manager apps from agents by default, and it prevents agents from typing into password or one-time-code fields. A user can temporarily allow a banking or wallet app for a specific task, while each newly connected agent requires approval and receives only the scope the user grants. Those default restrictions and per-agent scopes are described in the repository.

Device coverage and run records

Pinky documents support for Android 10 through 17 and iOS 17.4 or later. Its desktop application runs on supported versions of macOS, Windows and Linux, while Android emulators and iOS Simulators can stand in for physical devices. The repository lists the operating-system, phone and simulator requirements.

On Android 13 and later, an agent can work on a hidden secondary display, leaving the phone’s primary screen available to its owner or switched off and locked. Older Android devices and iPhones use the main display. Clicking the desktop mirror pauses the agent for manual control, and touching an Android phone also pauses it. Pinky’s documentation explains its display behavior and takeover controls.

Each run can include plain-language step descriptions, screenshots and a screen recording marked by step. Pinky says these records can be exported as an HTML report and remain on the user’s computer. The project page documents its recording and export features.

Analysis: the boundary still needs testing

Analysis: Moving approval enforcement outside the agent’s instructions is Pinky’s most consequential design choice because it gives the agent no stated route to approve itself. The unresolved issue is recognition: where a rule depends on Pinky spotting a risky on-screen button, its practical protection depends on what the gateway correctly classifies. The repository claims coverage across 10 languages, but it also labels the software pre-alpha and says some built functionality still awaits testing by a person. That makes the gateway a security design to evaluate, not evidence that every mobile workflow will be classified correctly. Pinky states both its button-detection scope and its pre-alpha testing status in the repository.

The project reports end-to-end Claude Code runs on physical Android and iPhone hardware, alongside support for USB or Wi-Fi connections and computer-based unlocking. It directs prospective users to its acceptance documentation for the current feature status and testing instructions. Those implementation-status claims come from Pinky’s own project page.

Teardown packages 3D machine simulators for Claude Code

David Díaz — Tue, 10 Nov 2026 20:38:09 +0000

Teardown is an MIT-licensed GitHub project that provides a Claude Code skill for producing an offline, one-page HTML simulator from a plain-language request about a machine. For developers building technical demos or explainers, the relevant constraint is that the project aims to put the interactive model, surrounding numeric panels, a control that opens the active part, and an unattended tour into that same page. The project README describes this as a simulator that can be taken apart.

A constrained output format

The repository’s suggested installation command is npx skills add elvarofficial/teardown -g -a claude-code. It then calls for npm install and npx playwright install chromium in the installed directory, with Node.js 20 or newer required. The README lists ffmpeg as an extra dependency for video output and Python 3 for sound. The project README documents those prerequisites.

Its example prompts cover a four-stroke motorcycle engine, a mechanical watch and a hydraulic excavator arm. The repository also contains three complete example machines: a V8, a Cessna and a Strandbeest. The project README identifies those examples and prompts.

The project separates a machine definition from its interactive and recorded forms: the -shared variant is the machine, -live is the page a user drives, and -film is the recorded tour. Its build.mjs script bundles a machine into a single HTML file with three.js and fonts inlined. The project README describes that layout and build step.

More than a browser demo

Teardown also includes a capture path. Its capture.mjs tool renders a film frame by frame to a 60 fps MP4 or emits review sheets of still images; the repository’s sound tooling generates procedural audio on the film timeline. The project README lists those capture and sound components. The project credits whaleyxbt/claude-motion for the runtime, frame capture, sound engine and review rules. The project README names that upstream dependency.

The unresolved question is fidelity

Analysis: Teardown is most clearly a packaging and presentation workflow, rather than evidence of a validated engineering-simulation system. The README specifies how a generated machine should look, behave in a page, be reviewed and be recorded, but it does not describe a procedure for calibrating a model against physical measurements or validating its numerical behavior. The project README documents the workflow and bundled examples.

That leaves a specific trade-off for teams using it: a single-file interactive teardown can be useful for explanation, design discussion or demos, but the repository alone does not establish that its displayed values or motions are suitable for engineering decisions. Developers should treat physical fidelity as a requirement to verify separately, not a property supplied by the presentation pipeline.

AnyModelBot Splits Local Agent State From Remote Inference

David Díaz — Sun, 08 Nov 2026 20:39:56 +0000

AnyModelBot’s maintainers have published an MIT-licensed personal-agent application for Windows, macOS and Linux, with desktop, command-line, Docker and local web-console modes. It can route model requests through Modelflare or supported vendors’ official APIs. The project repository documents the available deployments and model routes. Analysis: For developers, the immediate consequence is a deployable agent control plane on their own machine—not a guarantee that model inputs remain there.

Separate bots, workspaces and permission levels

Each bot has its own persona, default model, workspace and memory. The documented tools can read and write files, execute commands and operate the desktop, subject to the selected permission level and platform capabilities. The repository describes these bot boundaries and tools.

The permission model has three levels. Read-only mode restricts changes. The default workspace mode limits the bot to its own folder and asks before it crosses that boundary. Full-permission mode runs without the sandbox, although recursive deletion still requires approval. Those distinctions are specified in the project’s permission documentation.

AnyModelBot also supports background jobs and scheduled rules. Long-running work can continue while the user has other conversations, then return its result to the original thread. The listed messaging integrations are WeChat, Feishu, Telegram, Slack and Discord; the repository says those external channels currently handle one-to-one conversations rather than channel group chats. The supported task and messaging behavior is described in the README.

Model selection also selects a data route

The repository says one Modelflare account provides access to more than 70 text, image and video models from 13 providers, with token-based billing. It presents GPT, Claude, Gemini, Grok, DeepSeek, Kimi and GLM among the available families and says AnyModelBot itself has no subscription fee. These are the project’s stated Modelflare and pricing terms.

Users can instead supply official API keys for OpenAI, Anthropic, Google Gemini, xAI, DeepSeek, Kimi, GLM, Qwen, MiniMax and Mistral. In that configuration, requests go directly to the selected vendor rather than through Modelflare, although the repository says image and video generation currently requires Modelflare. The direct-provider route and its limitation are documented here.

The local side includes conversations, memories, workspace files, API keys and login tokens. The remote side can include prompts, file contents and tool results needed for a response, plus screenshots when computer-use tools inspect the display. Messages sent through connected chat services also pass through those platforms. The repository’s privacy section explicitly divides data along these lines.

Modelflare retains request logs when it proxies a request, with retention details delegated to its trust documentation. Using an official provider key removes Modelflare from that request path, but the selected model vendor still receives the request. The project states both routing conditions in its privacy disclosure.

Analysis: Local control does not settle data exposure

Analysis: AnyModelBot’s defensible distinction is between the location of the agent’s state and the location of model inference. Workspaces, memory, credentials and the agent runtime remain under the user’s control, while the information required to run a selected model follows either the Modelflare route or a direct vendor route. That is a narrower and more useful definition of “local-first” than treating the whole system as local. The documented architecture supports this separation.

The unresolved trade-off is authority versus disclosure. The default workspace gate can prevent an agent from crossing its folder boundary without approval, while full-permission mode deliberately removes that sandbox. Neither setting changes the need to transmit task context when a remote model must interpret a file, tool result or screen. Approval therefore constrains some local actions; it does not by itself make the task data local. The permission and privacy documentation exposes both sides of that trade-off.

Developers evaluating AnyModelBot should treat provider routing, bot permissions and connected messaging services as one security boundary. A direct vendor key removes the Modelflare intermediary, not the model provider. Restricting a bot’s workspace narrows its local reach, but tasks using connected channels or computer control introduce additional data paths. Those paths are enumerated by the project rather than hidden behind the local-first label.

Unslop Brings Staged UI Review to Claude Code and Codex

David Díaz — Mon, 02 Nov 2026 20:39:26 +0000

Unslop is a GitHub-hosted skill for Claude Code and Codex that targets what its author describes as “vibecoded, AI-looking” interfaces. For developers, the concrete change is an ordered review process: the skill audits a screen and proposes a design direction before it begins editing. The project documents the workflow and installation steps on GitHub.

From audit to ordered revisions

The audit identifies patterns including purple gradients, glows, emoji labels, forceful copy and uneven spacing. Unslop then derives a direction from the product, covering its character, visual world, limited uses of color and a signature detail. Its edits proceed through spacing, color, icons, copy, type, layout, details, visuals and motion, in that order. Those stages are specified in the project README.

The README says the skill can work on dashboards, applications and landing pages built with Next.js, React, Vue, Svelte, Tailwind, or plain HTML and CSS. It can also inspect a live-site URL. Users invoke it with /unslop in Claude Code or $unslop in Codex, although the repository says an agent can also select the skill from a request written in ordinary language. The supported inputs, stacks and commands are documented here.

If the initial screen is already satisfactory, the intended behavior is to suggest limited refinements instead of carrying out a full redesign. The proposed direction appears before edits, giving the user an opportunity to steer it early, but the documentation does not describe a mandatory approval gate. The README states both behaviors.

Optional media features add dependencies

For hero visuals, Unslop can use image services such as fal, Replicate, OpenAI Images or Higgsfield. If no service is connected, it can offer to connect one as an MCP server; the project says it displays the prompt and asks before each paid generation. The image-generation workflow is described in the repository.

The skill can also create a square story video, lasting under 10 seconds, that shows the interface changing. Live-site snapshots and story videos require Playwright and its Chromium browser, while video output additionally requires ffmpeg on the system path. The repository lists these dependencies.

Unslop uses the CC BY 4.0 license. The README permits modification, sharing and commercial use provided users credit creator Damir Sokolovsky and link to the repository. The licensing conditions are published with the project.

Analysis: a review rubric, not evidence of better design

Analysis: Unslop’s more consequential idea is not automated CSS editing but the conversion of a subjective critique into an inspectable sequence. Surfacing the audit and proposed direction before the ordered passes gives developers a clearer point at which to challenge the agent’s assumptions. That interpretation follows from the workflow documented by the project.

The unresolved trade-off is that a repeatable rubric can also standardize one author’s aesthetic preferences. The project page defines recognizable visual clichés and provides examples, but it does not report usability testing, product metrics or comparative evaluation establishing that removing those patterns improves an interface. Developers still need an independent review of whether the proposed direction suits the product and its users. The repository shows the project’s documented scope and evidence.

MOSS-Image Publishes 5B DiT Weights and Layout JSON Workflow

David Díaz — Fri, 23 Oct 2026 19:43:29 +0000

OpenMOSS has published code and weights for MOSS-Image-Base and MOSS-Image-SFT, giving developers a 5B-parameter DiT text-to-image model with a documented JSON layout-prompt format. The practical consequence is that text placement and composition can be expressed as structured input rather than left entirely to a natural-language prompt. The project repository describes the model as targeting text rendering, layout generation and efficient fine-tuning.

Two published variants and conventional entry points

The repository lists MOSS-Image-Base as its base text-to-image model and MOSS-Image-SFT as a version fine-tuned from the base on curated data. It provides a Python example built around diffusers.DiffusionPipeline, and documents a Gradio application for local use. The same repository also says MOSS-Image is supported natively in ComfyUI, with built-in loaders for ComfyUI-format weights.

For inference, the documented defaults are Flow-matching Euler sampling, 50 steps, CFG 3, shift 5, and negative-branch skipping at layer 22. These are project recommendations, not independent performance measurements. The repository's sampling table also documents GPU-resident, component offload and sequential memory modes, with sequential mode trading inference speed for lower memory use.

Layout is part of the prompt interface

MOSS-Image's most concrete control mechanism is a JSON input format containing a scene summary and an items array. Each item can include a label, description, optional text to render and a bounding box; the documented example uses centralized pixel coordinates and a yxyx box format. The layout guide in the repository instructs users to match those coordinates to the requested output dimensions and to pass the JSON as the prompt string in the Python API.

That makes the interface suitable for tooling that already has deterministic scene metadata—for example, an editor that knows where a headline or illustration should sit. It does not establish that a generated image will exactly obey every coordinate or render every string correctly; the repository presents examples and capability claims, but no evaluation methodology or benchmark results in the supplied documentation. The project page characterizes text rendering and layout control as key highlights.

Analysis: The useful distinction here is between a model that can be asked for a layout and one whose layout can be represented, stored and edited as data. MOSS-Image documents the latter interface, which could make generation pipelines easier to integrate with design tools. The unresolved trade-off is reliability: developers will still need their own validation loop for text accuracy, box adherence and composition quality because the repository does not supply quantitative evidence for those properties. The documented JSON workflow supports structured authoring, while the page's stated capabilities remain project claims.

Fine-tuning and licensing boundaries

The repository says community tooling includes full fine-tuning and LyCORIS training, including LoRA, for both model variants. It specifically points to KohakuMossTrainer, which the project says supports several precision modes, multi-GPU approaches and adapter training with as little as 6GB of VRAM. Those details appear in the repository's release notes, so teams should verify the linked trainer and its hardware assumptions before treating that memory figure as a deployment requirement.

The standalone pipeline code is released under the Apache License 2.0. The repository license section does not, in the supplied page text, separately spell out the terms governing every published model weight or every third-party community artifact. Developers planning redistribution or commercial deployment should therefore check the relevant weight and dependency terms rather than infer them from the pipeline-code license alone.

DigUp Searches Local Media, Documents and Code On-Device

David Díaz — Wed, 21 Oct 2026 19:40:00 +0000

DigUp is available as a free, open-source desktop application for searching selected local documents, images, recordings, videos and source code. Its macOS build is accompanied by beta releases for Windows and Linux. For developers, the immediate consequence is one search interface that can locate a function, screenshot, PDF page or point in a recording without uploading those files to a hosted service, according to the project repository.

One query, two retrieval paths

DigUp runs Google DeepMind’s EmbeddingGemma 2 through llama.cpp. Its readers convert files into text, pictures or sound representations, then store vectors for pages, passages, images, video frames and audio segments in a SQLite index. Those vectors occupy the same 768-dimensional space, allowing one text query to rank different media types together, according to the implementation description.

Semantic retrieval is only one part of the search path. DigUp also maintains a keyword index and boosts exact-word matches, which is intended to preserve literal searches for names, invoice numbers and error codes that an embedding may not represent precisely. Queries therefore combine vector proximity with lexical matching rather than treating embeddings as a substitute for exact search, as the README explains.

Indexing granularity depends on the format. DigUp processes PDFs page by page, splits audio into overlapping 30-second windows, and samples video frames while also indexing the soundtrack. Search results can point to a PDF page or media timestamp, although jumping directly to that location depends on the viewer available on each operating system, according to the supported-format and playback notes.

Code stays in a separate index

Code search is disabled until the user enables it for selected folders. It reads source files, notebooks without their outputs and repository documentation, then opens matches at the relevant line in a configured editor. The code index remains separate from general file search, and code queries must begin with code:, according to the code-search documentation.

The project says this path skips files ignored by Git, along with vendored or generated code, data files and content that resembles a key or password. It lists support for editors including VS Code, Cursor, Zed, Sublime Text and JetBrains IDEs, plus several platform-specific options, in the same documentation.

Local processing still has a cost

The maintainers state that indexed content does not leave the computer and that DigUp has no account requirement or telemetry. The application connects to download its model once and to check for updates once per day; the update check can be disabled and is described as sending no information about indexed files. These are claims made by the project itself.

That design shifts computation and storage onto the user’s machine. The initial model download is 865 MB, and the first indexing pass can take from minutes to hours depending on the selected files and hardware. DigUp estimates that duration during setup; on Windows and Linux it uses a GPU when a setup check finds that path faster than the processor while producing the same results, according to the installation and performance notes.

Platform constraints are uneven. The Mac version requires Apple Silicon and macOS 14 or later. Windows requires 64-bit Windows 10 or 11, and its beta installer is not yet signed. The documented Linux packages target 64-bit Intel and AMD systems, with .deb and AppImage distributions available from the project’s releases and installation instructions.

Analysis: broader retrieval means broader access

Analysis: DigUp’s consequential design choice is the combination of cross-media vector ranking with exact-string retrieval, not semantic search alone. That can make fragmented project material searchable through one interface, while the separate code index limits accidental mixing between repositories and personal files. The architecture and separation are documented in the repository.

The unresolved trade-off is scope. Better retrieval requires granting the application access to more folders and paying the corresponding indexing cost. Folder selection, opt-in code search and exclusions for several sensitive file categories narrow that boundary, but they do not remove the need to decide which local material belongs in a consolidated search index. Those controls and exclusions are described by the project; judging whether they are sufficient remains a user-side trust decision.

cleanyourtv Debloats Android TV and Replaces Its Home Screen

David Díaz — Mon, 19 Oct 2026 19:45:30 +0000

cleanyourtv packages Wi-Fi Android debugging, package-disable scripts and a replacement Home launcher into one workflow for Android TV and Google TV. For developers, the consequence is a reversible way to modify a television without root or a cable: selected packages are disabled rather than uninstalled, and the project provides restore tooling.

The workflow changes package state

Setup requires a computer on the same Wi-Fi network as the television. Users must enable USB debugging, authorize the computer through the television’s debugging prompt and, when a separate Network or ADB debugging option is present, enable that too. The documented quick start uses a coding assistant with shell access, while a manual route is available through Python 3 tools and shell or PowerShell scripts. Project instructions

Before making changes, the workflow backs up the installed-package list and settings. It then applies model-specific selections with Android’s pm disable-user; the supplied disable.sh and restore.sh scripts apply or reverse the same debloat list. The project’s checklist also asks which apps the user needs and whether voice assistance, Chromecast and system updates should remain enabled. Package-management workflow

A small launcher supplies the new Home screen

The replacement app, com.gathin.tvhome, is described as roughly 280 KB installed. It is written in Java with AndroidX RecyclerView and designed for televisions with 1 GB of RAM; the repository says it uses no network connection, background services, video or blur effects. Building it requires JDK 17 and Android SDK platform 34. Launcher documentation

The project describes the resulting interface as Apple TV-style. It includes a dock, a top shelf for the focused app, an application grid, input controls, network status, settings access, themes and a clock screensaver. Launcher feature list

The installation scripts query which package owns Home and disable only launchers they recognize as tvlauncher or launcherx, unless the operator supplies an override or chooses to leave the stock launcher alone. The build-and-install script also rolls back if the new launcher does not become Home. Installation behavior

Compatibility stops at OS boundaries

The repository reports 54 tested TV lists across 23 brands. Its detailed list is not limited to television sets: it also covers streaming boxes, sticks and projectors, including Chromecast with Google TV, NVIDIA Shield, Xiaomi devices, Fire TV hardware and XGIMI projectors. Tested-device lists

The project targets Android TV and Google TV. Samsung televisions running Tizen and LG televisions running webOS use different systems. Fire TV can use the debloat portion, but Fire OS does not assign Home to a third-party launcher; the repository also notes that some China-market TCL sets refuse launcher installation. Platform limitations

Analysis: The project’s central engineering choice is to treat disabled-package state as the rollback boundary instead of deleting software. That makes restoration possible, but it does not remove the need for device-specific judgment. The checklist concerning voice assistance, Chromecast and updates shows the unresolved trade-off: packages considered bloat may also participate in integrated services a household wants to retain. A restore script can reverse state changes, but it cannot make that selection for the operator. The documented workflow and restore model

Solid Glass Adds an AI UI Theme to shadcn/ui Projects

David Díaz — Sat, 17 Oct 2026 19:44:14 +0000

Solid Glass is a public GitHub project that packages a glass-inspired design system for AI applications as a stylesheet intended to work with shadcn/ui. For developers building chat and agent interfaces, its practical proposition is narrow but useful: the stylesheet targets the data-slot attributes and classes that existing shadcn/ui components already carry, so adoption is presented as a theme integration rather than a component rewrite. Source: Solid Glass repository

A theme layer, not an AI framework

The project describes its visual treatment as sitting between flat design and “liquid glass”: surfaces retain outlines, borders, highlights and shadows, while avoiding the highly transparent treatment that can interfere with text legibility. Its stated design goals are tactility, precision, physicality and materiality; for interfaces with streaming responses, agent tasks and pending human decisions, it argues that neutral surfaces and reserved use of colour and motion help keep the UI calm and readable. Source: Solid Glass repository

The core distribution is one CSS file. The repository says it defines colours, three glass thicknesses, a state and motion, while also defining shadcn/ui’s variable names. It supports light and dark modes, although the project describes dark mode as the intended material treatment. Source: Solid Glass repository

Installation begins from a shadcn/ui project using React 19, Tailwind CSS 4 and Base UI components. Developers add the deeplethe/solid-glass/solid-glass stylesheet through the shadcn CLI, import it after Tailwind and shadcn styles, and remove the :root and .dark colour variables created by shadcn initialization because Solid Glass defines variables with the same names. Source: Solid Glass repository

Components for agent-facing screens

Beyond the theme, the project supplies installable components including status-glyph, panel, tag, dot-loader, turn-status, composer, tool-steps, diff-view, ask-card, context-ring, task-notice and reasoning. The README positions these around an agent workflow: showing activity, accepting a prompt, rendering tool steps and diffs, asking for user input, and displaying context usage. Source: Solid Glass repository

The repository also includes complete screen-level “Blocks,” including an agent-workspace, plus a Create page that exposes controls for thickness, tint, chart colour, type, radius, rim and blur and produces corresponding CSS variable changes. Source: Solid Glass repository

The compatibility trade-off

Analysis: Solid Glass’s most consequential choice is to treat shadcn/ui as the compatibility surface rather than create another self-contained component ecosystem. That should reduce initial adoption cost for teams already on the shadcn stack, because the theme is designed around existing slots and classes. It also leaves an unresolved maintenance question: the approach depends on those structural conventions remaining stable enough for a stylesheet to keep selecting the intended parts. The repository notes that some displayed shadcn/ui components differ slightly from stock versions, while saying the stylesheet does not depend on those differences. Source: Solid Glass repository

This is therefore best read as a focused UI layer, not evidence of a broader agent runtime or application framework. Its value will depend less on the glass treatment itself than on whether its component conventions fit a team’s existing shadcn/ui codebase and the information density of its AI workflows. The repository is licensed under MIT and includes contribution, code-of-conduct and security-policy materials. Source: Solid Glass repository

ARTEX Preserves Its Final Version as a Pure-Source Backup

David Díaz — Thu, 15 Oct 2026 19:42:56 +0000

ARTEX’s maintainers are preserving the autonomous penetration-testing system’s final version as a pure-source backup. The former autumn27/artex Docker image is unavailable, so the repository now directs users to the maintained mianhuatang11/artex image or a local source build. Developers evaluating or operating ARTEX should note that these deployment paths have different update behavior, as documented in the project repository.

The project describes ARTEX as the champion entry in Baidu’s “agent+” attack-and-defense competition. That designation is the maintainers’ description and should not be read as independent verification of either the contest result or the system’s effectiveness against real targets. The repository page is the source of the claim.

A planner, workers and two linked graphs

ARTEX combines a Go monolithic backend, a statically exported Next.js frontend embedded in the Go binary, and PostgreSQL storage. Exploration requires an LLM configuration through Anthropic or OpenAI credentials or the application’s interface. Its documented agent roles include goal decomposition, a planner, multiple workers and a human-in-the-loop main agent. The architecture documentation describes these components.

The system separates its data into two linked structures. A shared asset graph stores domains, subdomains, IP addresses, services, applications and endpoints. A task-specific exploration graph stores goals, intents, facts, findings and hints, while anchors associate those records with individual assets. This separation supports both an investigation’s lineage and asset-level coverage views, according to the dual-graph design.

The planner reads the exploration state and dispatches uncovered directions as intents. Workers claim one intent at a time, run tools and write resulting assets, facts or findings back to the graphs; those changes can wake the planner for another cycle. Workers can also search traces from other work items in the same task, excluding their own current trace. The engine documentation specifies this event-driven loop and cross-worker search.

Controls around execution and retesting

ARTEX documents a recording MITM proxy for tool traffic and guard and intercept components that provide approval gates. Its interface exposes activity streams, approval records, traffic recordings, asset coverage and human-in-the-loop conversations. The repository’s subsystem and interface documentation lists those controls and views.

Vulnerability retesting runs in a separate agent session rather than restarting the original scan. A retest can conclude that an issue remains reproducible, has been fixed or cannot be confirmed. A successfully completed retest marked as fixed can update the vulnerability’s status automatically, while the original evidence and report remain available. The retesting documentation defines that workflow.

Deployment has two update layers

The installation script supports either an all-Docker deployment or a locally compiled application, while Docker Compose and a manual source build are also documented. The backup repository does not host precompiled binaries; it instead refers users to releases from the original repository when available. The installation instructions describe these options.

ARTEX’s in-application updater replaces the program but not the Docker image. The documentation warns that tools bundled in the image, including Playwright and nmap, are not updated through that path, and recreating the container restores the application version included in the image. Updating the full environment instead requires pulling and recreating the ARTEX container. The update documentation distinguishes these procedures.

Analysis — ARTEX effectively treats the application binary and its containerized security toolchain as separate release units. The unresolved operational issue is release coordination: an application-only update leaves bundled tools unchanged, while container recreation can replace the application with the image’s bundled version. Teams adopting ARTEX should therefore decide which combination constitutes a tested deployment and track both layers rather than treating the two update paths as interchangeable. This interpretation follows from the project’s documented Docker update behavior.

Aurelio Pairs Local Finance Records With an Optional AI Adviser

David Díaz — Tue, 13 Oct 2026 19:42:29 +0000

Aurelio is a public, MIT-licensed personal-finance application that runs on the user’s computer and keeps its records there. Its AI adviser is optional and connects through OpenRouter with the user’s API key. Developers can therefore clone and run the financial tracker locally while deciding separately whether to configure the external AI integration. The repository documents the license, local operation and optional adviser.

A ledger for assets, liabilities and goals

Aurelio records banks, brokers, cash and dated holdings. Its portfolio views calculate position costs, gains and dividends, while its fund look-through breaks exposure down by country, sector, company and currency. The app also covers recurring investments, homes, debts, income, expenses, savings rates and the returns required for financial goals. These functions are listed in the project README.

Running the demo requires Git, Node.js 22 or later and uv. The supplied macOS, Linux and Windows scripts start the app with an invented household and open it at http://localhost:8000. The repository provides the requirements and demo commands.

For non-demo use, records reside in backend/data.db. The project says it saves a copy beside that file before an update changes the data format. The storage path and pre-update copy behavior are documented in the README.

The repository also documents separate backend and frontend test commands using pytest and npm test, plus hot-reload commands based on Uvicorn and the frontend development server. Those development workflows appear in the project documentation.

The adviser introduces a second boundary

The “Ask Aurelio” chat answers from the user’s records, can search the web and presents proposed changes as cards that the user must confirm. Enabling it requires an OpenRouter account with credit and an API key stored in backend/.env; users can select a model in the chat. The repository describes the chat behavior and OpenRouter configuration.

Analysis: Local record storage and local AI processing are not the same property. Aurelio keeps its ledger on the user’s machine, but the optional adviser routes through OpenRouter and can use those records when answering questions. Developers evaluating the app should therefore treat storage and AI processing as separate trust boundaries rather than reading “runs on your own computer” as a claim that every enabled operation remains local. That interpretation follows from the project’s description of local records and its OpenRouter-backed adviser.

The confirmation-card flow provides a visible checkpoint before a proposed change is accepted. Analysis: It does not settle the separate question of what financial context is appropriate to submit to an external AI service. The unresolved trade-off is between the adviser’s record-aware answers and web search on one side, and keeping the application free of that external integration on the other. The underlying confirmation, record access, web search and optional-AI behaviors are documented by the project.

OpenDots Packages Persistent Agents for Chat, Calls and Slack

David Díaz — Sun, 11 Oct 2026 19:38:51 +0000

OpenDots is a public, MIT-licensed template for building persistent AI “coworkers” that can work through documents, text chat, voice calls and Slack. For developers, the important constraint is that it is not a hosted agent product: teams run the application, configure its infrastructure and connect the external services that make conversations, calls and computer tools work. OpenDots repository

The project organizes work around Spaces and specialist “Dots.” A Dot can receive a name, role instructions and permitted tools, while its access can span multiple Spaces. Pages live in the local workspace database and support a searchable library, a visual editor, autosave, revision checks and page-specific conversations. OpenDots repository

Agent work with explicit approval points

OpenDots includes two notable controls for agent actions. A Dot can present a draft through a human-in-the-loop card, where approval creates a page in an authorized Space; changing the draft requires a new review. For MCP-connected tools, read-only tools run directly, while other tools pause for an Approve & run decision in chat. Tool availability can also be enabled or disabled for each Dot. OpenDots repository

The template can also attach a separate computer to each Dot through OpenBot’s container supervisor and computer service. Its browser profile and workspace files persist across stops and starts, and the interface exposes browser control, files, terminal output and human takeover. The repository is explicit that an unconfigured template does not execute commands on the host. OpenDots repository

For communications, the project describes continuous text conversations, voice calls that pair realtime speech with a separate compute agent, and a Slack integration built with Channels SDK. Calls and longer-running work share the same conversation context and tool permissions, according to the project documentation. OpenDots repository

The deployment boundary is the product boundary

A developer can create Spaces, write pages and configure Dots locally before connecting services. Chatting requires an Intelligence project and a model configuration; calls additionally require a speech provider, while Slack and computer features need their respective setup. The architecture uses AG-UI between the application and agent interface, plus CopilotKit components and runtime, TanStack AI, Threads, and Channels SDK for Slack. OpenDots repository

That distinction matters because OpenDots separates local workspace data from conversational and provider data. Pages, workspace metadata and thread bindings are stored in SQLite, but conversation messages, tool calls and run events are persisted in the configured Intelligence deployment. In the hosted configuration, those records go to CopilotKit’s cloud; the configured model provider receives conversation context, including authorized page content and tool results. OpenDots repository

Public-web research has another boundary: queries and selected URLs go to Parallel by default unless WEB_SEARCH_PROVIDER=disabled is set. Speech and messaging integrations send data to their configured providers when used. The repository also documents telemetry opt-outs through COPILOTKIT_TELEMETRY_DISABLED=true or DO_NOT_TRACK=1. OpenDots repository

Analysis: OpenDots’ useful contribution is not a claim that agents can safely operate unattended; it is the attempt to make the intervention points visible in the application: per-Dot permissions, approval cards, isolated computer services and explicit provider configuration. The unresolved trade-off is operational rather than cosmetic. A team that wants persistent agents across documents, Slack, voice and browser tasks must also own the integration surface, permission design and data flows that those channels introduce. The repository’s own separation of local page storage, conversation persistence and external provider traffic makes that responsibility hard to ignore. OpenDots repository

invisible_playwright_mcp Pairs MCP With Stealth Firefox

David Díaz — Fri, 09 Oct 2026 19:40:53 +0000

invisible_playwright_mcp packages a browser agent as an MCP server and a local web UI, while its maintainer claims the underlying Firefox engine is undetected by anti-bot systems and CAPTCHAs. For developers, that means assistant clients can drive page interactions with configuration that may retain login state, route traffic through a proxy and send page content to an external provider. The repository documents each of those behaviors.

Two interfaces to the same browser

The repository provides installation paths for Claude Code, Codex and Gemini CLI. Its standalone interface runs locally, presents chat beside a live browser and requires an OpenRouter key. The same package starts the MCP server when invoked without a subcommand and launches the interface with the ui subcommand. The project also points Python developers to invisible_playwright, a related library whose API follows Playwright’s.

The README says the agent interacts through pointer movements and key presses. Configuration includes proxies, seeded browser identities, persistent profile directories and a headed mode. The project says a repeated seed produces the same browser identity, a profile directory preserves cookies and logins across restarts, and proxy selection determines timezone, locale and network egress. These options are described on the project page.

Analysis: The anti-detection promise is stronger than the evidence presented on the repository page. The claim appears without a target-site matrix, testing protocol, success rate or independent validation. That does not establish that the claim is false, but it leaves developers without a documented basis for estimating reliability against a particular site’s defenses. The repository page presents the claim and configuration details but none of those measurements.

Local execution still has external data flows

The project says the agent runs on the user’s machine and has no server of its own. Sessions, profiles and screenshots are stored locally. However, sites receive browser traffic, the web UI sends its conversation and page content read by the agent to OpenRouter, and an MCP client sends corresponding information to whichever provider it uses. Those boundaries are set out in the project’s privacy policy.

The engine is downloaded from a GitHub release when the server or interface first starts, and a GeoIP database is downloaded when a proxy is configured. Each browser launch also fetches a one-line counter file from a GitHub release. The project says that request carries no identifier, although GitHub sees the originating IP address as it would for another HTTPS request. The maintainer says nothing else is collected or sent to the author.

The README warns that changing the interface host from its loopback default exposes a service with no authentication. It also says passing an OpenRouter key on the command line places the key in shell history and, on Linux, the process list; using an environment variable or local .env file avoids those two exposures. The project documents both warnings.

The unresolved control boundary

Analysis: Pairing persistent browser state with an agent intended to appear less detectable shifts the central deployment question toward authorization and review. A profile can preserve cookies and logins, page data can leave the machine, and a host change can expose an unauthenticated interface. The unresolved trade-off is whether teams can gain useful browser access without granting overly broad access to stored sessions or sensitive page content. Those risks follow from the project’s documented persistence, data-flow and host settings.

The project tells users to read the terms of sites they visit, respect rate limits and avoid submitting anything that a human has not reviewed. Its responsible-use guidance places those obligations on the operator.