Aiden Adds Per-Network Wi-Fi Proxy Routing for Its Device Agent

Major Update: We merged PR #652 in the open-source Aiden firmware repository, adding per-network Wi-Fi proxy routing. The change reduces repeated environment edits when you move Aiden between configured Wi-Fi networks with different connection requirements.

The problem we fixed

Before this update, changing networks could require you to edit proxy environment variables again. Different networks might need a direct connection, a particular proxy protocol, or destinations that bypass the proxy. Reapplying those choices manually made it harder to keep the active environment aligned with the network currently in use.

The merged implementation associates proxy behavior with each configured Wi-Fi network. When the active network changes, managed Aiden paths can refresh against that network’s assigned behavior instead of relying on a repeated manual change.

What changes in Aiden

Config Web’s Wi-Fi connection dialog now supports system default, direct, HTTP, HTTPS, SOCKS5, and SOCKS5H modes for each configured network. It also supports a network-specific NO_PROXY bypass list, so destinations that should not use the proxy can remain separate from proxied traffic.

The active network environment is provided to managed commands and login shells through a local listener at 127.0.0.1:18080. Managed Agent connections refresh when the proxy scheme or bypass rules change. SOCKS5H remains distinct from SOCKS5 because it preserves destination DNS resolution through the proxy.

These settings live with the network definition in Config Web. You can therefore keep one behavior for a home network, another for a restricted network, and a direct mode where a proxy is unnecessary. The implementation describes the supported modes and refresh path in the reviewed firmware change; it does not extend that list to every possible proxy arrangement.

What you can do now

You can associate a proxy policy with each configured Wi-Fi network and let managed Aiden paths adopt the active policy after a network change. Managed commands, login shells, and Agent connections receive a consistent environment without requiring the same proxy values to be edited in several places.

This is useful when the same device moves between networks with different egress rules. A direct connection can remain direct, an HTTP or HTTPS proxy can be selected where required, and SOCKS5 or SOCKS5H can be reserved for networks that need those protocols. NO_PROXY rules can be kept with the network that needs them.

The current boundary

The work in PR #652 is merged repository code with documented validation. Go, system environment, Config Web, shell, and related tests passed, and the firmware binary build passed. Luckfox validation covered service health, the SOCKS5H environment, web access, and a Qwen request.

These results document the reviewed implementation and test path. They do not establish deployment to every Aiden device or product, support for every network or endpoint, or any general privacy, security, speed, or uptime guarantee. Inspect PR #652 for the change record and follow Aiden’s continued open-source development.

Aiden Extends Phone Bridge to Remote Mobile Agent Benchmarks

Major Update: We merged PR #636, PR #643, PR #655, and PR #656. This merged change set extends environment bridge mode so it can proxy Aiden App Phone Bridge traffic between a bridge Agent and a remote Agent, creating a more direct route for real-device benchmark relay workflows.

The problem we fixed

The bridge Agent remains the endpoint your Aiden App connects to for Phone Bridge traffic. When an environment bridge endpoint is configured, the bridge Agent can proxy eligible traffic to the remote Agent through that configured route.

Foreground traffic uses bidirectional WebSocket forwarding. This means the bridge can forward active Phone Bridge communication in both directions between the connected sides, rather than treating the session as a one-way command submission. The proxy also reports remote connection status, helping the Phone Bridge-facing side understand whether the remote route is connected.

Background traffic follows a different path. Commands use the configured environment bridge’s HTTP queue path, where they can be queued, polled, and routed toward the remote device environment. Available results return through the configured environment bridge route.

This is the core architectural improvement behind the remote Phone Bridge workflow: your Aiden App can address the bridge Agent while related traffic is relayed toward the remote Agent and its device environment.

What changes in Aiden command handling

The queue path now has clearer behavior when no work is waiting. Empty command polls return commands as an empty array, providing a defined no-command response for polling clients.

Clipboard writes also validate text before queueing. This adds input validation before clipboard-write content enters the background relay path. It does not establish that every accepted clipboard write has completed on a target device.

Input routing changes are specifically conditioned on an environment bridge endpoint being configured. Under that condition, iOS keyboard actions and enter_text skip local USB HID isolation and proceed through the remote input path. This is not a general change to local USB HID behavior when no environment bridge endpoint is configured.

Benchmark daemons can now relay Phone Bridge commands through the device environment Agent. That arrangement gives a mobile agent benchmark a route from the benchmark-side daemon through the device environment, instead of requiring the benchmark layer to act as the final device-control endpoint.

What you can do now through a real-device benchmark route

You can connect the Aiden App to the bridge Agent and exercise related command paths through a real-device benchmark route. The routed scope includes app-related interactions, URL capabilities, clipboard operations, calendar commands, contact commands, and local-notification capabilities.

For an Aiden App benchmark workflow, this means the bridge-facing connection can direct these command categories through the configured environment bridge and device environment Agent. The practical value is access to an additional routed exercise path for supported capabilities, not a claim that every capability has been validated across every benchmark setup.

Reviewed validation included Go tests and a manual clipboard_read round trip through benchmark relay mode. That manual result confirms one clipboard-read path was exercised through the relay route and returned through the expected flow.

The current boundary for routed commands and outcomes

This update is merged code with reviewed validation. It is not confirmation that the change is deployed to every device, benchmark environment, or Aiden App installation. It also does not establish complete benchmark coverage, universal iOS or Android compatibility, or a measured benchmark improvement.

Keep command handling states distinct. A queued acknowledgement indicates that the queue accepted or recognized a request. A routed command indicates that transport directed it through the configured environment bridge. Neither state alone proves that the remote Agent executed the command or that the target device completed the intended action.

A confirmed device-side outcome requires explicit returned evidence. You can use this new route to exercise supported capabilities through a real-device benchmark path, while treating each device result as separate from queue acceptance and command routing.

Aiden Adds a Self-Knowledge Skill for Clearer Agent Boundaries

Major Update: We merged PR #624, adding an English Hermes-style self-knowledge Skill for the Aiden Agent. This merged open-source firmware content gives the Agent a bundled reference for describing its current project context and limits more directly.

The problem we fixed

Questions about an Agent’s own environment need answers grounded in the project rather than broad assumptions. When you ask Aiden what it owns, where work routes, which setup path applies, or how recovery should proceed, the answer needs to distinguish documented context from an inference.

The Aiden self-knowledge skill addresses that need with a project-specific reference. It documents hardware ownership, runtime routing, Phone Bridge behavior, board configuration, phone setup, observation, verification, and recovery boundaries.

That scope matters because these subjects are related but not interchangeable. A request may involve routing, a device setting, or a recovery path, while the appropriate response depends on what is actually documented for that part of the project. The Skill gives Aiden a clearer basis for stating those boundaries without implying that it can independently discover every capability, configuration, or device condition.

What changes in Aiden

The new Skill serves as AI agent capability documentation for the Aiden firmware and its device-side agent runtime. It is bundled reference material intended to make answers about the current project context more direct.

For you, that means questions about Aiden’s hardware responsibilities, tools, routing, board configuration, phone setup, Phone Bridge behavior, or recovery path can be answered with a more explicit description of the relevant boundary. The content does not expose companion-app internals. Where companion-app context is relevant, it remains limited to public behavior and settings.

The Skill also reinforces a practical distinction that matters in real workflows: an acknowledgement is not proof that a task is complete. An acknowledgement can show that a request was received or accepted. Verified completion requires appropriate evidence from the relevant observation or verification path.

This is a narrower and more useful standard for agent runtime boundaries. It helps prevent status language from getting ahead of the evidence available to the Agent.

What you can do now

You can ask Aiden more focused questions about the areas covered by the bundled reference, including its documented responsibilities, runtime routing, configuration context, phone setup, and recovery guidance. The improvement is not a setup tutorial or a complete guide to the current development board. It is a clearer source of project context available to the Agent.

Recovery guidance is deliberately specific. During frame-service recovery, stale images must not be used as evidence for deciding what happened or for claiming that recovery succeeded. That warning applies to the frame-service recovery path and should not be treated as a broader rule about every image-related workflow.

We validated the merged Skill with skillopt lint reporting zero issues, YAML frontmatter validation, focused Agent skill-loader tests, and git diff checks. These checks support confidence that the content is formatted, loadable, and reviewed in the firmware repository. They do not guarantee that every future answer, task, setup attempt, or recovery action will succeed.

The current boundary

The Aiden self-knowledge skill improves how the Agent describes the project it is part of. It does not make the Agent infallible, guarantee every answer, or establish automatic discovery of every available configuration.

This update is merged open-source firmware content, not a deployment announcement for every device, product configuration, or user environment. Its value is straightforward: when you need Aiden to explain its documented scope, it now has a more direct reference for doing so while preserving the limits of what can be verified.

Aiden Adds Smarter Notification Memory and One-Step Cleanup

Major Update: We merged PR #605, PR #613, PR #614, and PR #594. These firmware changes refine AI agent notification memory, add a deliberate one-step cleanup path, and improve lifecycle handling for cancellation-request state. The code is merged into the open-source Aiden firmware repository; its verification scope is described below.

Separating public information from personal facts

Notifications can contain very different kinds of information. A news alert may repeat public material, while a billing notice, delivery update, appointment, or device alert may carry a fact related to you. Treating both categories as the same type of memory makes it harder to keep the information that is useful to your ongoing tasks.

The updated extraction logic distinguishes public information from facts related to you. This gives the memory path a clearer basis for deciding what belongs in user-related notification history instead of treating everything in a notification as equivalent.

Retention is now explicit as well. Temporary notification memory follows a seven-day rule, while long-term notification memory follows a 90-day rule. These periods define the reviewed implementation’s boundaries; they do not mean that every notification is retained or that classification cannot make mistakes. For you, the practical change is a more bounded model for short-lived details and longer-lived personal information.

Cleanup stays under your control

The Web UI now gives you two confirmed choices: clear the current session, or clear the session together with memory. The selected scope is visible before the operation proceeds. Cleanup remains an action you request and confirm rather than an unattended background event.

At the API layer, the clear operation removes backend sessions and realtime-context sessions, then creates a clean root session. That root gives Aiden a defined place to continue after the previous session state has been removed.

The two choices let you match the reset to what you need. You can start a clean session without selecting the broader memory action, or explicitly clear both session and memory when that is the intended result. This makes AI agent memory cleanup easier to understand while keeping control with you.

Reclaiming completed cancellation state

The merged work also improves the lifecycle of cancellation-request tombstones. Aiden reclaims those markers after associated work finishes, during result cleanup, and at shutdown. This prevents completed cancellation state from continuing to grow indefinitely after the work it represents has reached its cleanup points.

The notification-classification work was verified on a development board for classification behavior and cursor advancement. The reviewed evidence does not claim a complete regression result, so this update does not infer broader validation beyond those documented checks.

Taken together, the changes establish clearer notification memory management: public information and personal facts are treated as distinct categories, temporary and long-term records have defined retention windows, cleanup requires your confirmed choice, and completed cancellation markers are reclaimed through their lifecycle.

This update does not claim support for notification sources or platforms beyond the reviewed facts, nor does it present the classification as infallible. You can inspect the linked pull requests for the merged implementation and follow Aiden’s continued open-source development.

Aiden Adds Context Pruning and Recoverable Agent Sessions

Major Update: We merged PR #609, PR #618, PR #608, PR #607, PR #622, PR #621, and PR #592. This coordinated runtime update strengthens AI agent context management by making active context, session persistence, and provider-driven continuation more explicit for long-running work. The code is merged into the open-source Aiden firmware repository; its verification scope is described below.

The problem we fixed

Long-running sessions can accumulate large tool results and state that is no longer useful for the next request. If all of that material remains active until general compaction begins, it consumes the Provider’s input budget and makes the current work compete with stale history.

Aiden can now evaluate historical tool results and expired state against the available input budget before compaction. Eligible historical content can be pruned while the current turn is retained, so the request you are actively working on stays in context. This is context pruning for AI agents, not a rule that removes the current turn or preserves every earlier detail indefinitely.

Pruning also has a clear boundary. The Provider remains responsible for general compression, while Aiden manages the session-level decision to remove eligible historical results and expired state. The context_prune_threshold setting is now a migratable input-budget ratio instead of a fixed token count. This makes the threshold relative to the Provider’s available budget and keeps the configuration portable as that budget changes.

Recoverable session lineage

The same merged work clarifies what Aiden persists and how a session continues after a Provider truncates context. Session events are now the persistence source. The unused historical mirror has been removed, reducing ambiguity about which record represents the durable session history.

When the Provider reports context truncation, Aiden can rotate the work into a child session. The new session records its parent-child lineage rather than appearing as unrelated work. If you inspect a continuation later, that relationship gives you a traceable explanation of how the active session followed the earlier one.

This structure supports persistent AI agent sessions without overstating the result. Recorded lineage does not guarantee that every detail from a previous context window can be reconstructed or that every interrupted task will resume identically. It establishes a durable session relationship and a defined continuation path when provider limits are reached.

Safer active-session updates

The active-session pointer now follows the same consistency model. Aiden updates .current_session through synchronized atomic replacement, avoiding exposure of a partially written pointer while the current-session reference changes.

Together, the responsibilities are easier to follow: session events provide persisted history, .current_session identifies the session to resume, and lineage records when a child session follows provider context truncation. You get a more explicit model for tracing long-running work across session boundaries and restarts.

The context-pruning implementation in this merged series was cross-built and deployed for verification on Luckfox hardware. That is a specific verification step, not a claim that the update has been deployed across every Aiden environment or behaves identically under every configuration.

One limitation remains documented: first-turn token-estimation accuracy after a restart is still a follow-up concern. The update improves session persistence and continuation, but it does not present restart token estimation as complete. You can review the linked pull requests for the implementation record and follow Aiden’s continued open-source development.

Aiden Adds a Mobile-Friendly Browser Terminal for Device Debugging

Major Update: We merged PR #604, replacing Wetty with ttyd 1.7.3 and adding a mobile browser terminal at the standardized /webtty/ path. The merged change brings terminal implementation, routing, and supporting Aiden services into closer alignment, giving you a more consistent browser entry point when you need to debug from a phone-sized screen.

The problem we fixed

Before this update, terminal links, reverse-proxy routing, health checks, and the terminal implementation could require separate configuration. When multiple Aiden components needed to reference the same terminal service, that separation created unnecessary ambiguity around which route each component should use.

The previous setup also made browser access less uniform than intended. A browser-based terminal is most useful when its entry point is predictable, but mismatched route expectations could complicate both access and maintenance.

Mobile access introduced another practical issue. Terminal text sizing and scrollback behavior were less comfortable on phone-sized browsers, making it harder to read output, review command history, and inspect an active system without moving to a larger display. Those details matter when you need to troubleshoot in the moment.

What changes in Aiden

PR #604 replaces Wetty with ttyd 1.7.3 and standardizes the terminal route as /webtty/. Aiden now uses this path consistently across the terminal experience rather than maintaining different route expectations among related services.

Agent Web, Config Web, and Docker reverse-proxy routes now point to /webtty/. Terminal links and health checks use the same standardized path, too. This shared route contract reduces uncertainty between the terminal link you open, the reverse proxy that serves it, and the check that monitors it.

The merged configuration also adjusts terminal font sizing, scrollback behavior, and client limits for mobile browser access. The result is a mobile browser terminal better suited to the constraints of reading and interacting with a command line on a smaller screen.

What you can do now

When your Aiden setup exposes the terminal through its configured browser and reverse-proxy path, you can open it through one consistent /webtty/ route. That means the route used by the browser, proxy, and health check is aligned within the firmware codebase.

For mobile debugging, you can work through the terminal in a browser with settings adjusted for smaller displays. Improved font sizing and scrollback behavior help make output and command history more practical to review from a phone.

Migration compatibility is also included for the previous terminal environment variables. Existing settings associated with the former terminal environment can continue through the migration layer as the firmware moves to ttyd-based configuration.

This update is focused on consistency and mobile access behavior. It does not remove your existing authentication, network reachability, reverse-proxy configuration, or device setup requirements. It also does not claim compatibility with every mobile browser or host environment.

Validation and availability

The merged implementation passed Docker contract, reverse-proxy, and Config Web tests. GitHub Actions also completed the final firmware and Linux builds, providing build validation for the change.

The code is merged into the open-source Aiden firmware repository. This is not a statement that ttyd 1.7.3 or the standardized terminal path has already been deployed to every Aiden device or product. Availability depends on the firmware version and deployment path you use.

Inspect PR #604 for the implementation details, and follow Aiden’s continued open-source development.

Aiden Adds a Unified Firmware Build CLI and On-Device Smoke Tests

Major Update: We merged PR #599, PR #612, and PR #569, adding a unified firmware build CLI, parallel CI checks, and board-local smoke tests. These changes are now merged in the open-source Aiden firmware repository, giving you a more structured path to build, validate, and diagnose firmware before moving into higher-level Agent troubleshooting.

The problem we fixed

Previously, build entry points and validation checks were spread across layers. That could leave you determining which command matched a build task, reconstructing the privileged container environment for an isolated command, or tracing a packaging failure without enough detail about the stage that failed.

Early hardware diagnosis had a similar dependency problem. A higher-level control or connectivity path could become part of the investigation before you knew whether low-level services were healthy. As a result, you could be debugging the Agent layer while the underlying display, audio, HID, or local service state still needed basic confirmation.

The merged work separates those concerns. It establishes a supported build path, isolates CI feedback by area, and makes it possible to check essential local behavior directly on the board.

What changes in Aiden

The build change makes build.sh the unified entry point for building binaries, building a complete firmware image, and running one-off commands inside the privileged build container. Instead of moving among separate scripts or manually recreating container context, you can use one entry point for the supported build modes.

This firmware build CLI also strengthens toolchain caching, reproducible timestamp handling, OTA key handling, and firmware-image packaging diagnostics. The improved diagnostics are especially useful when artifact assembly fails, because they provide clearer evidence about the failing packaging step rather than only reporting an unsuccessful outcome.

The validation boundary matters. The pull request did not complete a full local firmware-image build. Its result is described through CI and the reviewed technical implementation and validation recorded in the pull request. It should not be interpreted as proof of a successfully completed local full-image build.

The CI change restructures embedded firmware CI into independent parallel jobs for scripts, Docker, C++, Go, and Web checks. A failure in one area can be reported without waiting for unrelated checks in a serial path. This improves feedback structure and isolation, but it does not support a measured build-time percentage or a universal claim that every build is faster.

What you can do now

You can use build.sh as one supported build entry point for binary builds, firmware-image builds, and privileged-container commands. When packaging is the failing stage, you also have clearer diagnostics to help focus the investigation.

The new CI layout makes feedback easier to place at the relevant boundary: scripts, Docker, C++, Go, or Web. That organization helps you focus on the affected code or tooling layer without treating all checks as one undifferentiated result.

The third change adds board-local smoke-test scripts for HID, HDMI, audio, system state, and service logs. These on-device smoke tests run locally and do not depend on the Agent API, SSH, or network access. You can check low-level board behavior and inspect local service evidence before debugging Agent behavior or connectivity-dependent paths.

The current boundary

These smoke tests are intentionally narrow diagnostic tools. They are not complete hardware certification and not a full end-to-end Agent suite. They can help establish whether essential local subsystems and services appear healthy, but they do not prove every peripheral interaction, physical configuration, target-device scenario, or Agent workflow.

Likewise, these changes describe merged code, scripts, and CI architecture in the open-source Aiden firmware repository. They do not indicate deployment to every Aiden device or release, and they do not demonstrate production-wide behavior.

Inspect the linked pull requests above and follow Aiden’s continued open-source development.

Aiden Unifies Touch Gestures and Adds Visual Action Checks

Major Update: We merged PR #595, PR #602, PR #588, PR #598, PR #600, and PR #596 to give Aiden a unified touch-action contract and clearer post-action screen feedback. Within a supported device configuration, you can describe a swipe, drag, or atomic touch through touch_gesture, inspect the screen before releasing a drag, and receive a concise action result with its supporting image.

The problem we fixed

A device-control Agent needs two things from an action: a consistent way to express what it should do and a clear observation of what happened next. Before these changes, related touch actions did not share one complete contract. The result path could also carry image data both as a text result and as an attachment, adding information the model did not need to process twice.

Dragging creates an additional challenge. A single opaque drag command does not give the Agent an observation point while contact is still active. If the destination or visible state changes during the gesture, the Agent needs a chance to inspect that state before it releases contact.

The update addresses these problems together. It aligns the gesture interface, adds a defined inspection point to dragging, and makes action results easier for the model to consume.

What changes in Aiden

Swipe, drag, and atomic touch actions now use the touch_gesture contract. You can define a gesture by direction or by explicit start and end points. You can also set its speed, duration, and contact-hold behavior. This gives touch gestures for AI agents one vocabulary at the action layer while preserving the execution requirements of the configured device path.

A drag now runs as drag_start, a screen confirmation step, and drag_release. Aiden can begin the drag, preserve contact, provide the intermediate screen for inspection, and release after that confirmation step. The Agent is no longer limited to observing only after the complete drag has already ended.

Click-style actions now return a screenshot with a coordinate marker showing where the action occurred. Aiden calculates screen change before adding that marker, so the annotation itself is not mistaken for a change in the underlying screen.

The result format is cleaner as well. Screenshot status remains in the text result, while the image is delivered as an image attachment. Removing duplicated Base64 image content from the text path leaves the model with a shorter status message and the visual evidence it needs. The changes also remove obsolete screen-dimension state from the flow.

What you can do now

For mobile device automation, you can express supported gestures through the same action semantics for HID and Android ADB configurations. You can provide a direction for a common swipe, use explicit coordinates for a more controlled path, or tune duration and contact hold when the gesture requires it.

You can also make dragging more observable. The Agent can start contact, review the intermediate screen, and then release. After a click-style action, the returned screenshot identifies the target coordinate, while the change calculation still reflects the unmarked screen. This makes the action and its visual result easier to evaluate together without treating the marker as device activity.

The reviewed Go and Python validation reported 86 passing checks for the core touch-gesture work. That evidence covers the reviewed implementation and test context and gives you a concrete basis for further device-specific testing.

The current boundary

These changes are merged into the open-source Aiden firmware repository. They do not mean the update is deployed to every Aiden device, and they do not establish identical behavior across every operating system, input backend, or hardware configuration.

HID and Android ADB can use the same action semantics within supported configurations, but actual compatibility still depends on device type and setup. The 86 passing checks are not a claim of complete hardware or platform coverage. The update also does not claim perfect visual understanding, automatic recovery, or measured gains in speed or accuracy.

You can inspect the six linked pull requests for the implementation details, test Aiden with your own supported device configuration, and follow the project’s continued open-source development.

Aiden Adds a Cross-Platform Desktop Environment Bridge

Major Update: We merged PR #593, PR #615, and PR #611 to add a cross-platform desktop environment bridge for macOS, Linux, and Windows and complete the device health endpoint required by the shared protocol. These changes give Aiden benchmark and Agent workflows a common way to interact with supported desktop hosts while identifying environment state during preparation.

The problem we fixed

Before this work, benchmark and Agent workflows needed platform-specific environment handling. That meant a workflow preparing a desktop host could not consistently rely on the same environment interface across macOS, Linux, and Windows.

The device environment also had a distinct preparation failure: it could fail when its health endpoint was missing. The runner needs to identify the environment it is preparing before benchmark execution starts. Without a shared health signal, it could not establish the expected device context.

The merged implementation addresses both gaps. Desktop bridges now follow a shared environment protocol, and the device Agent now provides the health route the runner needs during preparation.

What changes in Aiden

The bridges cover macOS, Linux, and Windows. Through the shared protocol, they expose screenshots, mouse input, keyboard input, scrolling, dragging, and text entry. They also expose an HTTP health check, so the runner can inspect environment readiness before attempting a benchmark workflow.

This establishes a common desktop automation API at the protocol layer rather than requiring separate platform-specific handling at the start of each workflow. We also added protocol, routing, and platform tests to cover the new implementation and platform behavior.

On the device side, the Agent now adds GET /health. During preparation, the runner can use this endpoint to identify the device environment instead of treating a missing route as an unresolved condition. Before a run, a benchmark can check the platform, device type, and concurrency state. That gives the runner a clearer basis for determining whether the requested environment matches the benchmark’s requirements.

On macOS, the bridge now discovers system_profiler instead of relying on a fixed executable path. A fixed-path assumption can fail when the tool is present but not where the bridge expects it. Discovery makes host inspection more appropriate for differing macOS installations, while validation remains necessary on the host where you run it.

What you can do now

You can start the bridge on a supported desktop host, use the shared HTTP interface for screenshots and input actions, and check environment state before a benchmark run.

In practice, an Agent or benchmark workflow can request a current screenshot, send mouse or keyboard actions, scroll, drag, enter text, and query health through the same protocol shape on the supported desktop platforms. For cross-platform agent testing, the key improvement is a shared interaction boundary for core desktop actions and a preparation path that evaluates platform, device type, and concurrency state before execution.

The desktop environment bridge makes environment capabilities explicit so workflows can reason about what a host provides. Visual state comes through screenshots, input is expressed through defined actions, and readiness is available through health checks.

The current boundary

These changes are merged into Aiden’s open-source firmware repository. They are not a claim of deployment to every device or production environment.

macOS, Linux, and Windows support refers to the bridge implementations included in this work. It does not mean identical behavior or complete compatibility across every operating system version, desktop configuration, or host setup. Operating-system permissions and input backends still require validation on each host, and local configuration differences can affect screenshots and input actions.

You should validate the bridge and its health response in the environment where you plan to run a benchmark or Agent workflow. Inspect the linked PR #593, PR #615, and PR #611, and follow Aiden’s continued open-source development.

Aiden Can Now Install AI Agent Skills Directly from a URL

Major Update: We merged PR #586, giving Aiden a dedicated way to install supported AI agent skills from remote URLs. You can provide a supported HTTP(S), GitHub tree, or GitHub blob Skill URL, and Aiden routes the request to skill_manage install. The new flow stages the files, validates them, and publishes the Skill only after those checks succeed.

The problem we fixed

Before this update, a remote Skill URL could be interpreted as a general content-retrieval request instead of an installation request. The Agent might first use a web scraper, call shell or curl, create files manually, and then patch them into place. That was an indirect path for an action with a clear intent: install the Skill represented by the URL.

The extra steps also made it harder to understand where the installation stood. Content could be retrieved before the Agent had established whether the expected Skill files and structure were supported. A failed step could leave you inspecting multiple tool calls to determine what had been downloaded, written, or changed.

The reviewed real-Agent reproduction for PR #586 tested this with a natural-language prompt containing a GitHub Skill URL. After the routing change, the full trace used one skill_manage install call. It did not use the web scraper, shell, curl, or the manual create and patch actions.

What changes in Aiden

The new install action gives remote Skill installation its own controlled path. Aiden downloads SKILL.md and supported companion files into a staging area first. The staged content is validated before it becomes an active Skill. If validation succeeds, Aiden publishes the completed Skill atomically instead of exposing files one at a time while the installation is still in progress.

This separation between staging and publication makes the result easier to reason about. Retrieval prepares a candidate Skill; validation checks that candidate against the supported requirements; publication happens only after the candidate is accepted.

The action also returns concise metadata about the installation, file writes, changes, and integrity result. When a patch expects content that no longer matches the current file state, the updated feedback provides more useful mismatch details. You get a clearer record of what the dedicated action attempted and what it changed.

What you can do now

If you maintain a Skill at a supported HTTP(S) location or in a GitHub tree or blob, you can give its URL to Aiden in a natural-language request. You no longer need to guide the Agent through content fetching and manual file assembly for this workflow. The dedicated action handles staging, validation, and publication in sequence.

This is useful when you are testing a Skill revision, sharing a supported Skill location with another Aiden environment, or reproducing an extension setup from a known URL. The workflow reduces the number of unrelated tools involved and gives you installation metadata from one purpose-built action.

The current boundary

This update is merged into the open-source Aiden firmware repository. It does not mean the change is already deployed to all Aiden devices, products, or environments.

Direct installation is limited to supported URL formats and supported files that pass validation. Aiden does not treat arbitrary websites, repositories, or software packages as installable through this path. Validation also does not replace your responsibility to review third-party Skill content before using it in your environment.

You can inspect the implementation and reviewed behavior in PR #586 and follow Aiden’s continued open-source development.