Butler — your local AI office

Butler is a local marketing and research office with 115 configurable employees, 501 built-in skills, and you as CEO. Its lightweight 3D office has brick-style employees, desks, a coffee corner, a lounge, and your own glass-walled chamber. It runs locally on Mac or Windows, either as a packaged Electron app or in your browser. It is not a hosted service.

Scout, the researcher, reads approved AI publisher feeds, fetches original articles, checks dates and domains, and produces a brief with supporting evidence. Quinn, the social media manager, prepares LinkedIn and X drafts, checks their lengths, and publishes after your approval. Every post requires your explicit approval; background research never publishes on its own.

Desktop app (Mac and Windows)

The Electron app includes Butler, Chromium, Node.js, and a verified Ollama runtime. Users do not need Node, npm, a terminal, a separate Ollama installation, or a launcher shortcut. Open Butler.app on Mac or install Butler with the Windows installer. Closing the office window quits the app, cancels current work, unloads the model, and stops the Ollama service if Butler started it. Cleanup can take a moment when work is active. A second launch focuses the existing window.

On first use, open Office settings → Your local engine → Download to download the selected model (approximately 2.5 GB for Qwen3 4B or 1.4 GB for Qwen3 1.7B). Downloads can be paused and resumed. Model weights are not included in the installer. If Ollama is already running, Butler uses that service and its model storage, and leaves the service running when the app closes.

The app keeps its writable files outside the installation so upgrades do not overwrite the office:

• Mac: ~/Library/Application Support/Butler/
• Windows: %APPDATA%/Butler/
• Within that folder: data/ holds the database, .env holds private credentials, and runtime/ holds engine logs and downloaded models when Butler starts the bundled engine.

File → Open Butler data folder reveals this location. The packaged app starts with a separate office from the source checkout; it does not silently move or bundle your existing projects, credentials, imported skills, or model downloads. With both versions stopped, you can copy the checkout's data/ directory and .env into the app-data folder to transfer your office. Copy optional agents/ and skills/ there too if needed. Back up any existing destination office before replacing it.

The server remains private to 127.0.0.1:4310 so existing OAuth callbacks keep working. Stop the browser/terminal version before opening the desktop app. Social sign-in opens your normal browser using a short-lived, one-use handoff and a browser-bound callback cookie. The app picks up the saved connection on its next refresh.

Native access and future computer features

The isolated renderer gets a narrow window.butlerDesktop bridge: native text-file open/save dialogs (2 MB limit), folder selection, reveal app data, account sign-in, and model downloads. File operations act only on files chosen in the OS dialog. Native calls validate the owning window, main frame and local origin; external links allow HTTPS only. The renderer has no Node integration, raw IPC, arbitrary filesystem path API, or command runner. This follows Electron's security guidance.

Future filesystem and computer automation should add named main-process operations through this bridge. Screen recording, microphone, accessibility and automation permissions are not granted in advance; those features are not implemented yet and will require the appropriate OS permissions when added.

Build and verify desktop packages

Development/building requires Node.js 24 or newer; installed apps do not.

npm ci
node node_modules/electron/install.js  # only needed if npm blocked Electron's install script
npm run desktop:prepare             # download and verify this platform's Ollama runtime
npm run desktop                     # build frontend and run Electron
npm run test:desktop                # isolated profile; close any running Butler first
npm run desktop:mac                 # Mac .app/.dmg for the build machine architecture
npm run desktop:win                 # Windows x64 installer

Outputs go to ignored release/. electron-builder.yml uses an explicit source allowlist; .env, data/, .runtime/, optional private libraries and local model weights are excluded. Runtime downloads are pinned to Ollama 0.35.0 and verified against the release SHA-256 digests before extraction; licenses travel with the runtime. The Windows distribution is larger because it includes the engine's accelerator libraries.

The Desktop packages GitHub Actions workflow builds Apple Silicon, Intel Mac and Windows x64 packages on manual dispatch or a desktop-v* tag. Windows ARM is not a configured target. Building Mac installers requires macOS. The pinned NSIS toolset supports Apple Silicon cross-builds. For an unsigned Windows build on Mac, use npx electron-builder --win --x64 --publish never -c.win.signExecutable=false after runtime preparation. Test the installer on Windows before distribution.

These are local, unsigned/unnotarized builds until signing credentials are configured. macOS Gatekeeper and Windows SmartScreen may warn on distribution. Public releases need an Apple Developer signing/notarization setup and Windows code signing; the workflow does not publish releases or contain signing credentials. No auto-updater is enabled.

Open the office in a browser

Requires Node.js 24 or newer. Download it from nodejs.org.

• Mac: double-click Start Butler.command.
• Windows: double-click Start Butler.bat.
• Or use a terminal in this project:

npm ci
npm run build
npm start

Open http://127.0.0.1:4310. npm run launch builds, starts the server, and opens your browser. Keep its terminal open while the office works. Close that terminal window or press Ctrl+C to stop Butler and any local model service it started. During startup or active work, cleanup may take a moment. Closing only the browser tab does not stop the server. If another instance is already running, the launcher asks you to close it first so this window owns the instance it stops.

Start and stop from a terminal

Start an already-installed office (Mac or Windows): open a terminal in the Butler project folder and run:

npm start

On a Mac, you can enter the folder first with cd "/path/to/Butler" (replace that example with your actual folder). Then open http://127.0.0.1:4310/ in your browser. Keep the terminal open. After pulling frontend changes, run npm run build before starting; alternatively, npm run launch rebuilds and opens the office for you.

Stop normally: press Ctrl+C in the terminal running Butler. This lets Butler shut down gracefully. Closing the browser tab alone does not stop the app.

Stop an existing background instance on a Mac: this stops the server listening on Butler's default port, 4310:

lsof -tiTCP:4310 -sTCP:LISTEN | xargs kill -TERM

If nothing is running on that port, there is nothing to stop. To restart, stop the existing instance and run npm start again. Your drafts, settings, and saved connections remain on disk.

Using the office

Click Research news or speak to Scout to start a news round. Scout carries a folder to Quinn, who works at her computer and brings drafts to your chamber. Click her visit bubble, your character, or Your desk to read the brief, key points and posts. Give editorial direction and select Ask Quinn to rewrite for a new version, or edit the posts yourself. Approve & publish approves the current saved version and sends it to the selected connected accounts.

Drag to rotate the office, scroll to zoom, and click employees or their desks to talk. Idle employees walk to the coffee corner, window or lounge. The top-right Office journal holds real task statuses, dates, durations and results; the book opens Scout’s source library. Forms open over the office only when needed. Gentle motion reduces character bobbing and gestures.

Movement is a visual representation of real workflow events, not a separate AI simulation. Animation may finish after the underlying task. Publishing success always comes from API receipts, never from an animation. The help menu has an explicitly labeled handoff animation preview; it creates no tasks, drafts or posts.

The office starts with no active employees; no mock news, fake work, or fabricated publishing receipts are seeded. A real round can legitimately produce no drafts if nothing is recent, reachable, or readable enough.

Employees, departments and skills

Open Employees to search the roster, inspect skills, give assignments, and manage individual employees or an entire department:

• In the office: appears at a department desk and can receive work.
• On the bench: counted in the reserve lounge, with skills and history retained; cannot receive work.
• Undeployed: removed from the floor; cannot receive work. Redeploy anytime.

The eight sections cover research, marketing, creative content, analytics, technology, operations, compliance, and personal development. The office starts with no employees deployed. Open the Employees side drawer to see designations and skills, then drag an employee onto the office floor to deploy them in their department. A Deploy button supports keyboard and touch use. Use Assign work on a deployed employee to start an assignment, or Manage team & bench for the full roster. Deploy Scout and Quinn before news rounds; deploy Quinn before publishing. Deployment and skill changes are saved across restarts. Changes wait until the current assignment completes so a worker cannot disappear during a publishing operation.

All 115 employees and 501 skills work without external folders. The built-in capability catalog contains occupational/task names; Butler supplies original specialty instructions and reusable departmental methods. These are Butler implementations, not embedded copies of purchased prompt bundles, and do not claim to reproduce every technique in another library. Skill coverage starts with the employee's department; Skills & work lets you change it. Each assignment uses up to two explicitly selected skills, or chooses from assigned skills by relevance to the brief. Generic specialist instructions are sent to the local model; they do not grant shell, browsing, account or sending privileges. Job hunter uses its separate, restricted Job search workflow for discovery and applications.

Optional local imports can be placed in agents/subagents/<category>/*.md and skills/<category>/<skill>/SKILL.md; restart to load them. Plain frontmatter names/descriptions and Markdown instructions are supported, not arbitrary YAML execution or tool declarations. These folders are ignored by Git. Only import content you are entitled to use; keep restricted libraries private. The app never needs a paid bundle to start.

Employee cards show full 3D brick figures with department colors and individual hair and accessories. Hover or focus a card to get a wave. Dragging lifts the character with dangling legs; a successful placement adds a landing animation. Previews share one renderer and render only visible cards. Gentle motion and the system reduced-motion preference keep drawer figures still; a full-body illustration is available when WebGL cannot start.

Private projects and campaign work

1. Open Projects and create a brief with the company, website, products, audience, voice, research interests, confirmed claims and restrictions. No company or product is seeded in the public code.
2. Add up to eight public HTTPS source pages. Each assignment reads the website plus up to three additional pages; redirects are revalidated, private network destinations blocked, and response size/time bounded. This is source reading, not general web search. Failed reads are reported.
3. Save the brief, select a deployed employee, and request either a specialist report or Campaign posts & visual brief. Use reports for customer/competitor research, content planning or analysis. Completed reports are available under Skills & work → Recent work and in the journal.
4. Campaigns create separate LinkedIn/X copy, supporting source excerpts, an original project snapshot, the shortened model brief, visual direction, and a downloadable 1200 × 1200 PNG graphic. The graphic uses the campaign headline and project name; it is a designed text card, not generated product photography. Put essential facts first: local model prompts use bounded excerpts and may not include every long field.
5. Review the source material and claims at Your desk, edit if necessary, and choose Approve & publish. This sends text only to selected connected accounts. Download the graphic separately; image upload and paid ad placement are not connected. No post is sent just by running a campaign or completing a review report.

Project profiles, source snapshots, research results and campaign drafts are stored only in ignored local data/. Existing drafts retain their evidence when a profile is edited or removed. No project text or social credentials is committed to GitHub. The browser is still a trusted local interface: keep the app bound to loopback, and do not put it on a public server.

Small local LLM for an 8 GB computer

Default: Qwen3 4B through Ollama, a roughly 2.5 GB download, selected for better writing. In a live comparison on this 8 GB Mac, Ollama reported a peak loaded-model size of about 3 GB; a write, review and corrective rewrite took about 82 seconds. This is one measured example, not a speed guarantee. The operating system, browser and other apps need additional memory. Qwen3 1.7B remains available as a faster, lighter 1.4 GB option, with weaker writing and more review needed. Install that option with npm run setup:model -- qwen3:1.7b and select it in settings.

1. Install Ollama for Mac or Windows.

2. In this project folder, run:

   npm run setup:model

3. Start Butler. Check Office settings → Your local engine.

This checkout also supports a project-local Ollama executable at .runtime/ollama (Mac) or .runtime/ollama.exe (Windows). When present, Butler stores its model files in .runtime/models. Otherwise it uses your installed Ollama and its normal model storage. The optional runtime and downloaded model are not included in Git or npm dependencies.

Butler starts a local Ollama service if needed. A service started by Butler exits with Butler. An already-running Ollama service is left running because it may belong to another application. Model requests always use 127.0.0.1:11434, with no cloud model option. A service started by Butler has cloud features disabled, one model slot, and one inference request at a time.

News writing and review use a 4,096-token context; specialist and campaign assignments use 8,192 tokens for project evidence and skills and may use more memory. All passes disable thinking and bound output. Every inference sends keep_alive: 0, plus an explicit unload in cleanup. The settings panel checks Ollama's actual loaded-model list. Weights remain on disk but should not stay in RAM between jobs. Ollama's small service can still use some memory while the office is open. Other applications using Ollama can load their own models independently.

Turn off Use the local language model for a zero-LLM workflow. If Ollama is missing, fails, or produces invalid output, Scout records that event and falls back to a labeled extractive brief. This is a real source excerpt, not simulated LLM output. Basic fallback drafts are held for your review and cannot be automatically published.

How trust works—and its limits

• 156 curated source feeds: 19 publisher/research blogs and 137 official AI project release feeds. Examples include OpenAI, Google Research, Microsoft Research, AWS Machine Learning, Apple Machine Learning, MIT, Berkeley AI Research, PyTorch, Hugging Face, Ollama, vLLM, and LangChain. These are source feeds, not 156 independent news organizations. The Sources library has search, type filters, individual switches, and an Enable all button.
• The original five feeds plus 151 added feeds were checked for availability in September 2026. The catalog lives in server/sources.js and server/source-catalog.js. Availability changes; run npm run check:sources for a current public-feed audit. Reaching a feed does not guarantee its articles are readable or factually correct.
• Broad technology blogs are filtered for AI topics. GitHub sources are restricted to the named project's release feed and release paths, not the entire GitHub domain. The release API must confirm the exact tag, a non-prerelease public release, and its actual publication date. Editing an old release does not make it fresh. DeepMind's official redirects to blog.google are permitted.
• Hugging Face community and organization-hosted blog paths are excluded. Hosting on a reputable platform does not verify the author. Publisher policy is checked again before delivery; older noncompliant drafts are withheld on startup.
• HTTPS only, with publisher-specific domain checks on every redirect. No arbitrary web-fetching tool is exposed to the LLM.
• A 72-hour default freshness window; undated, stale, future-dated, duplicate, and unreadable articles are skipped. Previously rejected stories remain handled, so another scan does not recreate them.
• Scout fetches at most four feeds concurrently, checks publisher news before project releases, and gives different sources a turn. Up to 40 new articles can be tried per round regardless of the requested draft count. Blocked pages no longer exhaust a one-draft search after just four attempts. Scout's conversation and the journal report attempted articles, duplicates, blocked pages and other failures.
• Project-release verification uses the public GitHub API without an account token and is subject to its unauthenticated rate limit. A small ten-minute memory cache reduces repeated requests; publication freshness is always checked again. Rate-limited entries are skipped and recorded, never reconstructed.
• Article text is fetched before drafting. Blocked/paywalled articles are skipped rather than reconstructed from the model's memory.
• Each supporting excerpt is a complete sentence of at most 24 words and is checked against the fetched text.
• Quinn writes a detailed briefing, specific key points, a LinkedIn post with a factual opening and supporting paragraphs, plus a separate concise X post. Both posts link to the original. The short exact excerpt stays in the evidence panel.
• A second local model pass compares the claims with the article. Deterministic checks reject invented links, unsupported numeric strings, invented quoted names, copied first-person publisher voice, long copied passages, accidental language switching, and overlong X posts. Quinn makes at most one corrective rewrite. Unresolved concerns are shown beside a draft marked Editor flagged details and require careful CEO review.
• Model review is not independent verification and can miss errors or produce false alarms. The boss can correct a flagged draft and approve it. A rewrite keeps the previous version in local storage and clears approval; the interface displays the newest version.
• Manual edits clear approval. Every publishing path requires CEO approval. Legacy automatic-publishing preferences are ignored, and the API refuses enabling them.

“Source checked” does not mean independently fact-checked. A primary publisher can make mistakes, exaggerate, or use AI to write an announcement. Butler cannot prove an article is true or human-authored. It does not claim reliable AI-text detection or independent corroboration. Read the original before approval, especially for benchmarks, financial claims, allegations, or consequential news.

News rounds cover curated official announcements. Project assignments can read public HTTPS pages supplied by the owner, but do not search the whole web or independently corroborate claims. Campaigns include a downloadable typographic graphic and a visual production brief; photo generation, paid ad placement and image/video publishing are not implemented.

Social accounts

In Office settings → Connect your audience, save tokens from your own developer applications. Credentials are never passed to the LLM, returned to the browser after saving, or included in activity logs. “Credentials saved” is not a successful authorization test; access is checked at publishing time.

LinkedIn

Use a LinkedIn developer application with the appropriate product/access tier and OAuth permission: w_member_social for a member or w_organization_social for an organization with a permitted page role. Supply the user access token and author URN, such as urn:li:person:YOUR_ID or urn:li:organization:YOUR_ID.

Publishing uses the official POST /rest/posts API, not browser automation. The API version defaults to 202603 and is editable because LinkedIn versions expire. Your account must have access to this API; saving a token does not grant that access. See LinkedIn Posts API and OAuth authorization flow.

X / Twitter

Use an OAuth 2.0 user access token, with tweet.write, tweet.read, and users.read scopes. An application-only bearer token cannot post for a user. Publishing uses POST https://api.x.com/2/tweets and validates the standard 280-character weighted limit, including Unicode and shortened URLs.

X API usage can require paid credits. Set spending limits in your developer account. See X OAuth setup, create posts, and current pricing.

For X, configure a native/public OAuth 2.0 app with the exact callback http://127.0.0.1:4310/api/oauth/x/callback. Save its public Client ID in Office settings, then choose Connect with X from that address. Butler uses PKCE and a short-lived browser-bound state, stores tokens only on the server, and requests offline.access alongside the publishing scopes so it can refresh access on demand. Disconnect clears both active and refresh tokens locally; revoke the app at X to remove its provider-side authorization. Manual tokens remain supported but must be replaced when they expire.

For LinkedIn, enable Share on LinkedIn and Sign In with LinkedIn using OpenID Connect in your developer app. Register http://127.0.0.1:4310/api/oauth/linkedin/callback, then save the app Client ID and Client secret in Office settings. Connect with LinkedIn requests openid profile w_member_social, exchanges the authorization code on the local server, and obtains the personal author ID from LinkedIn’s userinfo endpoint. Tokens and the app secret stay in .env; reconnect when LinkedIn access expires. Manual tokens and author URNs remain supported for other approved integrations. Image/video publishing, threads, and scheduled individual posts are not implemented.

Delivery safety

The app records a receipt independently for each platform. A retry sends only platforms that have not succeeded. If a request times out or its success cannot be determined, it is marked Check account and will not be resent automatically. Check the actual account, then record either its post ID or that nothing was published. This also applies after a crash during delivery. No client can guarantee exactly-once delivery when a remote API accepts a request but loses its response.

Scheduling and local data

News rounds can run manually or every 1, 3, 6, 12, or 24 hours. The scheduler lives in the local server; the computer must be awake and Butler running. After a missed interval it runs one catch-up round. There are no OS background jobs or cloud workers. Scheduled rounds prepare drafts only, and pause when Scout or Quinn is benched or undeployed. Every post still requires CEO approval.

Task history includes employee, status, start/end timestamps, elapsed duration, and outcome. SQLite persists settings, worker deployments and skills, private project briefs, drafts, receipts, tasks, and events in data/butler.sqlite. The UI shows the latest 500 tasks/drafts and 150 timeline events; older records remain in the database. Dates are stored in UTC and displayed in your local timezone. Task durations are elapsed wall time, including waiting for a publisher or LLM.

Publishing credentials are stored in the project’s .env file, as requested. .env* and atomic-save temporary files are excluded from Git; .env.example contains blank placeholders only. Butler reads only its named credential fields on the server and does not load them into the environment inherited by Ollama. No .env variables are exposed by Vite, and credential files are blocked by the local HTTP server. Saved tokens are never returned by the status API, sent to the LLM, or logged.

.env is plaintext, not encryption. On macOS/Linux Butler restricts it to the current user (0600); Windows access depends on your user-folder ACLs. Keep this file and its backups private. Git ignore rules do not protect against manually sharing a file or force-adding it. Existing encrypted-vault credentials are migrated only when an .env key is absent; explicitly empty keys mean disconnected. The old encrypted vault is retained for recovery, so protect data/ as well. Disconnecting clears the active .env token; revoke provider access separately when needed.

Use official user OAuth access tokens in BUTLER_X_ACCESS_TOKEN and BUTLER_LINKEDIN_ACCESS_TOKEN, plus BUTLER_LINKEDIN_AUTHOR and BUTLER_LINKEDIN_VERSION. Safari login cookies are not API credentials. Each platform needs a developer application with the required publishing access; a saved value alone does not prove the account is connected.

Back up data/ only when Butler has stopped, keeping the database and any legacy encrypted credentials together. Back up the private .env separately. BUTLER_DATA_DIR can point to another private local directory. The HTTP server binds only to 127.0.0.1; it checks hosts, origins, and a custom header on writes. Do not expose it through a public tunnel or reverse proxy. It is a single-user local application, without multi-user authentication.

Development and checks

npm run dev      # local API on 4310 + Vite on 5173
npm test         # isolated workflow, API, model-lifecycle, and delivery tests
npm run build    # production frontend
npm run format  # format source files

server/ contains the local SQLite store, source reader, Ollama adapter, agent coordinator, encrypted credential store, and official publishing adapters. src/game/ contains the Three.js office, character routines and walking routes; src/OfficeGame.jsx connects it to real workflow events. The React desk panels hold drafts, preferences and history. The scene caps rendering at about 30 fps, pauses rendering in hidden tabs, and shares geometry to keep the office light on an 8 GB computer. test/ uses disposable databases and mocked publishing transports: running tests cannot publish to social media. The game and local writing flow have been exercised on this Mac; Windows launch scripts are supplied but have not been tested on a Windows machine. Live publishing still requires validation with your own authorized developer accounts.

Model references: Qwen3 4B and Qwen3 1.7B. Memory lifecycle: Ollama chat API and local-only configuration.

Job hunter

Open Jobs, deploy Job hunter, and upload a PDF, DOCX, or TXT résumé (up to 5 MB; scanned PDFs need OCR before upload). Save target titles, multiple cities/countries/regions, remote/WFH, hybrid or office/WFO arrangements, employment types, exclusions, posting age, and application contact details. Saved salary and eligibility/experience notes are review guidance, not verified eligibility or salary filters. Missing listing details are visible and can be excluded.

Find matching jobs reads Remotive's remote feed, the latest three Arbeitnow pages (mostly Europe), and optional Lever employer boards such as the company segment of https://jobs.lever.co/company-name. Use eu:company-name for an EU board. Each Lever board is capped at 1,000 listings. This is source-limited discovery, not an exhaustive search across the internet. Remotive listings are delayed by 24 hours and cached locally in memory for six hours; other source caches are shorter. Source failures and result counts are shown, and unknown publication dates are flagged. Changing a résumé or preferences requires a fresh search before applying.

Ranking uses saved title/location/work-arrangement filters and résumé skill overlap (common skills are detected when the skills preference is empty). The score is a keyword heuristic, not a hiring prediction. Review with Qwen adds a local evidence-based assessment, including gaps and saved salary/eligibility notes. The review receives bounded excerpts of long résumés/descriptions. Search and applications do not require a model; reviews use the existing local Ollama model. There is no cloud/subscription token integration, no credential import from Codex, and no change to other employees' model access.

Select up to 30 matches and click Apply to selected jobs to authorize sending your saved details and original résumé to those employers, sequentially. The visible browser adapter uses an installed Google Chrome, Microsoft Edge, or Playwright Chromium browser, in that order. For a development machine without Chrome or Edge, run npm run setup:jobs-browser once. Automatic application currently supports recognized Lever-hosted forms. It fills known contact fields, attaches the original résumé, and uses exact saved text/select answers. Unknown required questions, consent choices, CAPTCHA, changed forms, and unsupported sites need your input through the listing link. It does not bypass site challenges. The adapter only allows known provider/browser resources and restricts application writes to the chosen posting and Lever's résumé parsing endpoint.

A submission is marked Submitted only after an explicit confirmation on the expected employer posting, or when you explicitly mark a manual application submitted. Missing confirmations become Check submission, stop the queue, and cannot retry until you confirm no application was submitted. Restarting never resubmits an in-flight job automatically. Queued items return to review; in-flight items become uncertain. Stop cancels the active browser and leaves remaining items unsubmitted. Success history prevents duplicate submissions to the same normalized listing URL.

The résumé, contact details, preferences, and application history live in separate tables in the existing private local SQLite database, excluded from Git and desktop distribution. They are not included in the general office state, task log, or model prompts for other employees. The database is permission-restricted, not encrypted at rest. Clear private job data removes the saved job records; it does not withdraw applications already sent or erase external backups. Job pages are treated as untrusted content, and model prose cannot grant browser actions or invent application facts.

Provider references: Lever Postings API, Remotive API, Arbeitnow API. Employer-side submission APIs require employer credentials, so Butler uses the applicant-facing Lever form rather than asking applicants for employer API keys.

Additional job portals

Under Jobs → Where to look → Additional portals, enable LinkedIn, Indeed, Handshake, ZipRecruiter, Google Jobs, Wonderin.ai, Instahyre, Foundit, Atlassian, and/or Protocoljobs, then save preferences. Existing source choices remain unchanged until you enable these portals.

• Atlassian: public careers listings are read directly, including descriptions and locations. An update date is not treated as a publication date. Apply through Atlassian’s hiring site.
• LinkedIn: reads public search cards and attempts up to six full descriptions. Summary-only results are flagged. Tracking parameters and regional LinkedIn hosts normalize to the same job ID.
• Indeed, ZipRecruiter, Foundit: attempt public HTML/structured listings. If a portal blocks requests or changes its page structure, Butler reports a browser handoff instead of claiming there are no jobs. Foundit uses its India site.
• Handshake, Google Jobs, Wonderin.ai, Instahyre: browser searches/account workflows. These are not server-side feeds or automatic-application integrations. Google search links include your selected role and location; account-based portals show the query to enter manually. Wonderin remains a separate service; Butler never enrolls you, uploads your résumé to it, or uses its subscription.
• Protocoljobs: enter its exact HTTPS website address in preferences. No domain is assumed. Once configured it works as a browser portal with listing import.

The Your job portals panel provides each saved role/location combination. Automatic public searches are limited to the first four combinations per portal per run, with an hour of in-memory caching; all other combinations can be opened in the browser. Atlassian reads up to 2,000 feed records. Browser-only or blocked portals are listed explicitly in source coverage, without fabricated counts or dates.

Use Import a chosen job into Butler to paste a specific job URL. Read listing extracts public JobPosting structured data where available. If a page requires login or does not expose structured details, paste the title, company, location and job description yourself and save it. For Google Jobs, use the original employer listing. Imported jobs participate in local matching, Qwen review, duplicate detection and application tracking, and are re-evaluated on future searches. Jobs outside your preferences remain visible under All saved jobs.

These additions do not enable automatic submissions on the new portals. Only the existing recognized Lever adapter can submit; other applications are completed on the relevant site and explicitly marked submitted by you. Login cookies, passwords, API keys and subscription credentials are not collected. Public page reads use the same private-network and redirect protections as project research; pasted details never grant browser or model privileges.

Portal references: Atlassian careers, LinkedIn jobs, Indeed integrations, Handshake, Google Jobs help, Instahyre opportunities, Wonderin.