# Your AI Workspace Should Survive a Disconnected Phone Published October 7, 2026 UTC. Source: https://jwatte.com/blog/mobile-ai-workspace-lessons/ The desktop connected. Then it disconnected. Then it did it again. We had built a phone friendly interface, tested it in browsers, and promoted the container. The next user report described a repeating connection loop. That report was the reason to investigate, not a physical device certification. That was the point where a convincing deployment report met a less cooperative reality. The server did not need a more ambitious name or another model. We needed to reproduce the failure, preserve the working data, and stop calling an open connection a usable desktop. This is a field report from our October 4 through October 7, 2026 UTC work on the [Sovereign AI Playbook](/blog/sovereign-ai-playbook-remote-desktop-commander/). It covers what the release records actually show, what remained staged at the review checkpoint, and the choices I would carry into the next deployment. The [earlier architecture article](/blog/sovereign-advantage-dedicated-ai-workstation/) explains the hardware and economic tradeoffs. Here, the subject is what happens after the diagram.

Use the lessons on your own server: Download the deployment workbook, the redacted evidence summary, or this article as Markdown.

## A connection is not the same thing as a working screen Our failing mobile test opened its stream successfully. The unrepaired mobile WebKit fixture opened four stream connections in about three minutes and was marked unstable. The repair notes traced the failure to the initial video negotiation rather than treating a fresh login as the cure. The revealing detail was in the first negotiation. A mobile WebKit test with device scale three requested a **3840 by 2400** desktop at **288 DPI**. Our outer interface subsequently imposed **1280 by 800** at **96 DPI**. Setting sensible dimensions after an oversized stream had already begun was too late for this failing path. The unrepaired test opened four stream connections in three minutes. The final recorded repair test held one connection for three minutes; a separate Chromium engine fixture held one for six minutes. These are bounded regression results, not an uptime guarantee. No physical iPhone or iPad acceptance had been completed by the checkpoint. The automated stream tests used disposable desktops, not the live owner profile. The evidence also records a synthetic decoder failure test that preserved the unsent draft while recovering. [Connection evidence](/downloads/mobile-ai-workspace-evidence.json). The repair prepared the remote dimensions before the renderer started, offered JPEG compatibility for Safari, retained H.264 as a choice, and made the interface wait for rendered output before reporting Connected. JPEG was a compatibility decision, not a claim that it wins every bandwidth or motion comparison. The general lesson is to measure the experience you promise. Record connection attempts, actual rendered output, close reasons and retry state. Then test long enough to catch the loop. A screenshot and a successful socket handshake cannot do that job. Selkies already separates display resolution, scaling and stream controls. Those distinctions should remain visible in a custom interface rather than being folded into one mysterious Auto button. [Selkies web client documentation](https://docs.linuxserver.io/selkies/user-guide/web-client/). ## Mobile work needs its own controls The most useful phone improvements were ordinary interface decisions: reachable buttons, a local compose field, visible clipboard actions, and a way to select the remote window that matters. A phone should not need to navigate a remote browser just to ask a project question. The useful pattern is to link directly to the knowledge page, terminal, account approvals and maintenance. The desktop remains available when the task needs a desktop. We also separated local viewing from remote layout. Zooming a phone's view should not keep rearranging application windows on the server. Opening the keyboard should not become a series of remote resolution changes. For terminal input, local composition is especially helpful. Write the command or prompt in a normal text field, review it, and explicitly send it. Our multiline paste path requires confirmation and does not append another Enter. Esc, Tab, arrows and temporary modifier keys make more sense than expecting somebody to reproduce every desktop shortcut on glass. [Recorded interface and input checks](/downloads/mobile-ai-workspace-evidence.json). Clipboard access still belongs to the browser's security model. Safari requires appropriate user interaction and can show its own paste confirmation. A clear Copy or Paste button is more dependable than promising invisible clipboard synchronization. [WebKit clipboard guidance](https://webkit.org/blog/10855/async-clipboard-api/). A particularly frustrating case was an account approval link displayed inside the remote terminal. What looked like text on the phone was part of the desktop image. We built that page and tested its owner session, selectable fields, expiry and provider checks with synthetic accounts and codes. Those fixtures did not perform a fresh provider login. The lesson is not to weaken login. It is to make the legitimate login usable. ## Keep the workshop separate from its doorway The phone is a doorway. Webtop is another doorway. Neither should be the only place a job or project exists. The design gives host and desktop tools access to a shared working directory rather than requiring a new copy for every interface. The browser profile has its own persistent volume. Coding clients, model services and databases have separate roles and state. | Component | The job it should do | |---|---| | Webtop and Selkies | Present the desktop and carry deliberate user input | | Native coding CLIs | Inspect, edit and test the selected project through an authorized account | | Ollama and Hermes | Serve the explicitly chosen local model workload | | LiteLLM | Provide the application's configured model entry point | | Open WebUI | Supply the chat interface, with its own account and storage boundaries | | Qdrant | Hold an explicitly constructed semantic index, not automatically discover files | | n8n | Coordinate defined workflows and record their execution | An eight second synthetic job recorded state Completed and exit code zero. That record does not establish that a client detached during execution. It was a checkpoint demonstration, not proof of resilience after a disconnect or reboot. [Job receipt summary](/downloads/mobile-ai-workspace-evidence.json). A durable operation needs an identifier, a target project, an exit state and a saved result. On reconnection, read that record before starting again. Otherwise a helpful Retry button can submit the same work twice. Our next deployment would establish that contract before adding a large collection of tools. It is cheaper to decide what Completed means while there are three steps than after there are thirty. ## Installing Hermes did not give it our memory A model file beside a project folder has no automatic understanding of the folder. We transferred **409 exported Markdown memory notes**, preserved their source paths, checked them against a manifest, and created screened retrieval copies. Eight notes needed credential related redactions. The source originals were preserved. That count describes the complete approved Markdown export, not every file or conversation on the old machine. [Memory coverage evidence](/downloads/mobile-ai-workspace-evidence.json). The verified project route used SQLite FTS5 to retrieve relevant text before asking Hermes to answer. It attached source references and checked exact quotations. The plain general model remained a separate route. One failure was more instructive than a speed measurement: an early current release answer failed its expected version check. The implemented retrieval rule now replaces an older indexed copy with the live operational record for that specific current version question. A later test passed. Quoting a source and selecting current evidence are different responsibilities. I would keep that lesson even with a much larger model. Current state, historical notes and proposed plans are different evidence classes. A system that mixes them indiscriminately can return an elegant answer about yesterday. The local route used an **8192 token** context and bounded output. That was an operating choice, not a claim that the entire library fits into one prompt. Ollama documents the memory consequences of longer contexts and more parallel requests. [Ollama FAQ](https://docs.ollama.com/faq). ## Qdrant and n8n are integrations, not decorations It is easy to add two containers and say a product now has memory and automation. Our own evidence argues for more careful language. At the editorial checkpoint, Qdrant had persistent storage and authenticated access, and an initial semantic indexing job was still building. The established Hermes answer route was the tested lexical route. A database health response was not evidence that semantic retrieval had passed relevance, freshness and failure tests. The semantic design used local embeddings of already screened text, source coordinates, content hashes and product metadata. Results should be resolved against the current screened source, with stale mismatches rejected. A vector payload should not become a second, unverified source of truth. Its coverage needs a denominator, especially when only selected excerpts from large files are embedded. [Integration checkpoint](/downloads/mobile-ai-workspace-evidence.json). n8n needed an equally explicit handoff: a fixed internal endpoint, an appropriate credential, a stable request identifier and a workflow owned by the intended account. Our setup work also encountered a local CLI task broker port collision. A command being installed did not mean it could run beside the active service without configuration. Preserve the workflow store and the encryption key together as an operational responsibility, while protecting the key separately from public exports. n8n uses that key to encrypt stored credentials; replacing it casually can make a surviving database unusable. [n8n encryption key documentation](https://docs.n8n.io/hosting/configuration/configuration-examples/encryption-key/). For the next project, I would begin with a harmless health workflow, then a controlled index refresh. I would not begin by granting an automation unrestricted shell access, arbitrary destination URLs and an unbounded model budget. ## A new image should not require a new identity The reusable image should contain software and reviewed configuration, not a photograph of a live account session. Keep browser profiles, project files, model files, database storage and job records outside the replaceable image layer. Keep secrets out of Git and build arguments. Give each service only the runtime credential it needs, using supported secret files or protected configuration rather than assuming every application understands the same convention. [Docker Compose secrets](https://docs.docker.com/compose/how-tos/use-secrets/). Our desktop repair promoted a specific image while preserving the profile volume and existing application environment. It did not recreate the model and database services just to change the desktop. That narrower change made the result easier to verify. [Deployment evidence](/downloads/mobile-ai-workspace-evidence.json). There is a subtle trap here. The host CLI, a CLI inside Webtop, an account in Chrome and a provider API can each have a different authorization state. Updating Netlify or Wrangler does not authorize the correct account. A working desktop password does not authorize GitHub. Test from the exact execution environment you plan to use. Ask the CLI which account it sees, confirm access to the intended project, and perform a harmless read before a preview or production change. Keep private account details out of the published test report. ## A gateway does not turn subscriptions into unlimited APIs We retained the original separation between interactive subscription work and application model requests. A native coding client can use a supported subscription login. The dashboard uses the model routes actually configured in LiteLLM. These are not interchangeable credentials, and a gateway does not manufacture missing provider access. Our source aware local Hermes path was configured without a paid provider fallback. That is not an exhaustive test of every possible provider failure. LiteLLM supports configured fallback routes, but changing providers can change the cost, destination of the data and behavior of tools. That deserves explicit policy and tests. [LiteLLM fallback documentation](https://docs.litellm.ai/docs/proxy/reliability). The same care applies to remote prompting. Claude Code Remote Control lets a supported browser or mobile client continue work whose tools and files remain on the selected machine. A ChatGPT app needs an authorized connector that actually supports the requested action. Neither connection moves the provider's model onto your server or removes plan limits. [Claude Code Remote Control](https://code.claude.com/docs/en/remote-control) and [OpenAI connected app guidance](https://help.openai.com/en/articles/11487775-connected-apps-in-chatgpt). A useful remote prompt names the machine, project, permitted changes and completion evidence: > Use the enrolled server, not this device. Confirm its hostname and the project directory first. Read the current task record. Run the approved checks, save the result and show the changed files. Do not restart unrelated services or repeat a completed deployment. Ask for approval before any new production change. The wording is not a security boundary by itself. The connector, account permissions and server controls must enforce the allowed actions. It does, however, make a wrong machine or missing result easier to notice. ## Latest is a candidate, not a verdict The update request was reasonable: bring the CLIs and desktop components current without losing the environment. The unsafe interpretation would be to replace everything with whatever a floating tag happened to resolve to that morning. Our staged update work resolved an explicit package list to exact versions and a dependency lock. Its earlier dependency scan reported one critical finding and 48 high findings; a later scan reported zero critical and 37 high findings. Those are the two recorded scan results, not a claim that every dependency problem was eliminated. That audit concerns the candidate CLI dependency tree, not a count of independent exploitable flaws in the whole server. It also does not justify marking the system universally secure. [Scoped audit summary](/downloads/mobile-ai-workspace-evidence.json). I would use a weekly schedule to discover and test changes. Promote only the immutable candidate that passed the checks, not a fresh pull after testing. Save the previous image reference and configuration, then replace the affected service and check it again. For GitHub Actions, keep the trusted deployment mechanism separate from arbitrary repository scripts and untrusted pull requests. Give the workflow only the permissions it needs. A powerful persistent runner deserves particular care because changes to a workflow can become changes to the machine. [GitHub secure use guidance](https://docs.github.com/en/actions/reference/security/secure-use). The weekly updater was still under implementation at our reporting checkpoint. The workbook presents its acceptance contract, not a claim that an unattended pipeline had completed a successful update and rollback cycle. ## Recovery deserves its own test A candidate can pass syntax checks and still fail in use. Preserve the failing fixture, change the smallest relevant component, and run both the repaired scenario and the previously working paths. For this desktop, that meant keeping the original Selkies entry and earlier controls available, testing decoder recovery, checking actual input and transfer bytes, and verifying that a second tab could not silently take control. It also meant leaving real phone acceptance separate from browser engine tests. The backup policy had to be equally explicit. Our requested limit was **40 days for registered local backup files**. That is a local operating choice, not a universal recommendation. A cleanup job must distinguish those backups from active profiles, original migration sources and the working repositories. It must not follow a convenient filename into somebody's live data. A local archive can help undo a bad update on a working server. It does not prove recovery after losing that server. Database restoration, credential decryption and an independent recovery copy still need their own acceptance. The old environment was not cleared for retirement simply because the replacement desktop loaded. ## What I would do first next time Start with one protected desktop and one project. Confirm that the native account can read that project, and that a detached test job leaves an unambiguous result. Then replace the desktop container once and prove the project and profile survive. Add the mobile controls next. Test the keyboard, clipboard, window focus and file delivery before adding another model. Include Retina scaling, a decoder failure, a second controller, an expired login and a simulated connection loss. Follow the browser tests with an actual phone. Introduce project retrieval only after source identity and freshness are clear. Add semantic search and workflows as separate, bounded integrations. The two should improve the established path rather than turn one working service into a dependency on everything else. Finally, automate the proven release procedure. The [deployment workbook](/downloads/mobile-ai-workspace-fast-track.md) turns that order into a reusable checklist, a state inventory, test cases and prompts for a coding assistant. It deliberately is not a blind installer for an already occupied server. The point of a capable server is not to make failure impossible. It is to give work a durable home, keep evidence when a client fails, and make the next action clear. A mobile AI workspace starts earning its keep when reconnecting feels routine rather than like starting over. ## Fact check notes and sources The [redacted evidence summary](/downloads/mobile-ai-workspace-evidence.json) identifies the review window, failure reproduction, bounded connection tests, exported note coverage and staged update audit. It excludes account identifiers, private host addresses, session links, tokens and raw screen captures. Historical snapshots retain their dates. No universal reliability rate, whole system security certification or completed independent disaster recovery test is claimed. Vendor documentation supplies the general interfaces and constraints, rather than evidence that our deployment passed them: [Webtop setup and exposure warnings](https://docs.linuxserver.io/images/docker-webtop/), [Selkies controls](https://docs.linuxserver.io/selkies/user-guide/web-client/), [WebKit clipboard behavior](https://webkit.org/blog/10855/async-clipboard-api/), [Ollama memory and concurrency](https://docs.ollama.com/faq), [Docker secrets](https://docs.docker.com/compose/how-tos/use-secrets/), [n8n encryption](https://docs.n8n.io/hosting/configuration/configuration-examples/encryption-key/), and [GitHub workflow security](https://docs.github.com/en/actions/reference/security/secure-use). Continue with [the Sovereign AI Playbook](/blog/sovereign-ai-playbook-remote-desktop-commander/), [small quantized models on a 96 GB server](/blog/small-quantized-models-96gb-ai-server/), and [choosing desktop and browser agents](/blog/desktop-commander-cowork-browser-agents-small-business/). *Reporting reviewed October 7, 2026 UTC, using the preceding deployment records. The cover is a conceptual illustration, not a screenshot or proof of product capabilities. Product names identify the tools discussed and do not imply vendor endorsement.*