Jason 0.42.0

Jason 0.42.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.41.0

This release is about two things: how much of the sending you keep in your own hands, and your own AI changing Jason
itself. You say, for people who have not answered and for people who have, whether each message waits for your yes or
goes on its own. Where it goes on its own, a critic reads it first, and a doubt, a text nobody passed, a reply not yet
judged, a message written in the desktop's chat and the day's limit still bring it to you. Jason now knows which of the
two kinds a person is, and waits for a reply to be judged before it writes on its own to someone who just wrote; and a
person who asks not to be written to is never written to again, on any address. And your own AI can now change Jason
itself: its roles, its plugins, a route for every campaign and what a plugin is granted, from the command line or from
Open in, with a skill and a page that say how.

• Say how sends go, for people who have not answered and for people who have. Two named preferences,
  send_mode.cold and
  send_mode.warm, each automatic or every_message, set by a
  named person with jason preference set and read when a send is claimed. A campaign may hold a mode of its own with
  jason campaign set-send-mode <campaign-id> --cold … --warm …, set under a person's name and given back to the
  installation's preference with --clear; naming neither mode, and an archived campaign, are refused. jason status
  says which mode is in force for each kind of contact and where it comes from, and jason campaign get --human says
  the campaign's own. A mode nobody has set reads as every_message, so installing this release changes nothing about
  how your sends go, and every approval names the preferences still unset. No role sets a mode, and a request from
  inside a run is refused.
• Under automatic, a message goes without asking you, and some still come to you. Where the mode for a contact's
  kind is automatic and a named person set it, the claim releases a message, a reply or an invitation under an
  approval born approved, with the reason automatic_mode, decided in the name of the person who set the mode, and
  writes an approval_automatic_applied line. It goes only once the runtime's critic, or a person by name, has passed
  the text as it now reads. It waits for you instead, under an approval whose reason says why in one sentence, where it
  was written or edited in the desktop's chat; where its creator or a reviewer doubted it; where the contact has a reply
  not judged yet, or one judged before Jason recorded what kind of reply it was; where it answers no judged reply, or an
  automatic reply, a bounce or a request to stop, or a conversation a role marked for you; where nobody passed its text,
  or it was edited after the pass; and once the campaign has reached the day's ceiling. A standing approval still lets
  a reply go where it waits only for its contact's reply, for what it answers or for a review, as before; it never lets
  go one written in the chat, a doubted one or one past the ceiling. A retry reads the contact again, so a reply that
  landed in the meantime brings the message back to you. See
  the send mode at the claim.
• The critic reads each automatic message first. When a send to a person is created while the mode for its
  contact's kind is automatic, the runtime creates a critic work item for it in the same save, naming the send in
  the reserved context key send_review, and the send waits on it. Only that critic's pass, or a person's, lets the send
  go: a critic somebody queued by hand, or the critic of another send, is shown to you and releases nothing. Nothing is
  created under every_message, for a send that carries its creator's doubt, for one written in the desktop's chat, or
  where no critic could be launched; a critic that fails or ends without a review leaves the send to you, unless a
  standing approval covers it. The critic's skill knows that under an automatic mode its pass is the last look.
• A daily ceiling of automatic sends. Sending:AutomaticMaxPerDay, 100 unless you set it, from 1 to 1000, is the
  most sends the automatic mode releases from one campaign in a UTC day, counted since 00:00Z by the releases it wrote,
  whatever became of each. At the ceiling the next send waits for you with the reason daily_ceiling, and its preview
  says the limit, the count and since when; a standing approval does not let it go either, and a new day does not
  release it on its own. There is no 0 and no unlimited: to send nothing automatically, set the mode to
  every_message.
• The desktop's chat is never a person's word. Every request the chat's CLI sends carries the header
  Jason-Confined, and the runtime records it on the work, the edits, the verdicts, the reviews and the standing
  approvals made under it: a send written there always waits for you, a verdict there lifts no opt-out, a review there
  is no person's pass, and a standing approval set there sets nothing. The chat refuses a campaign's send mode and the
  send-mode preferences in every access mode and on every platform, refuses workitem.review, refuses a denied verb in
  any letter case, and can neither claim to be a run nor inherit being one.
• Send modes in the console. An approval card asks "How should messages go?" while a mode is unset, for people who
  have not replied yet and for people who have: Every message waits for you or Goes automatically, with
  Remember this. Settings sets the choice for every agent, an agent's own Settings tab sets its own, and System says
  which mode is in force and where it comes from. A doubted message shows on its card who doubted it and why, in their
  own words, and a held message says why it waits; one that went without asking you says so on its card, with the mode
  it went under.
• Jason knows whether a person has answered. jason reply record takes --nature: person, automatic, bounce
  or opt_out, in the runtime's own words. A contact is cold until a verdict that stands judges a reply of theirs, in
  that campaign, a person's answer; from then on they are warm. A reply nobody has judged yet makes the contact wait,
  even a warm one, since a new reply may be a request to stop; and where Jason cannot prove a reply judged, because a
  thread runs past one page or a read did not finish, the contact keeps waiting rather than being taken for warm or
  cold. See cold, warm or waiting and
  the Runtime API.
• A person who asks not to be written to is stopped on every address. A verdict whose nature is opt_out puts every
  address and profile the contact has on the do-not-contact register in the same act, by the runtime's own actor, and
  the claim refuses work about that contact in every campaign, including for a value they gain later. Only a person's
  own later verdict, under their name and outside any run and the desktop's chat, lifts it; a role's verdict, or a
  person named from inside a run, never does. A claim that refuses for this says opted_out. See
  the claim's checks.
• A doubt about a message reaches you before anything can release it. The one composing a message can say at
  creation, with --ask-person and a code, that you should look at it, and a role that reviews a message can pass it or
  doubt it with jason workitem review, bound to the text it read; an edit voids the review. A send can be created
  waiting on its review with --wait-on. A doubt goes ahead of a standing approval and of the automatic mode, so
  neither lets a doubted message go without you. Nobody reviews a message they wrote or edited, and a message edited
  under no name is reviewed only by a person by name. See
  doubts about a send.
• The quick-start skill reads your accounts before you say go. It tells you how many mailboxes and LinkedIn
  accounts are connected through the provider your sends go through, in the same message as the plan, and a read that
  fails or is slow never holds the question up.
• Change Jason itself. A new entry in the desktop's Open in menu, below Copy path, opens your own AI in a new
  terminal at Jason's role skills folder, with the plugins folder beside it where the AI takes a second folder (Claude
  Code and Codex), and a short first message that sets the session up for changing Jason. The AI is the one your
  preference agent.interactive_host names, else Claude Code, else Codex. It is offered in your own installation only,
  never in the demo. The desktop's chat still cannot change Jason's roles, plugins or settings, on purpose: asked to, it
  now says so and points you to this entry. See
  Changing Jason.
• jason session open --setup. The same session from a terminal: jason session open --setup [--host <word>] opens
  your agent host at the role skills folder, adds the plugins folder for Claude Code and Codex, and sends the setup
  brief as its first input. Every folder comes from what jason status reports, not from a remembered path. It starts
  no ...

Jason 0.41.0

Jason 0.41.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.40.0

This release is about a new person's first minutes and the numbers they see: three lines pasted into your AI install Jason and hand the ready installation to a new quick-start skill, which asks one question and drafts your first campaign; the console opens in any browser tab, with the desktop or without it; Settings gains a section for your name and tone; the demo opens on its sample in seconds; and the Dashboard counts over one period you choose, with replies by category and daily trends, read through a new reply.count.

• Three lines install Jason and take you to a first campaign. The README's Quick start now opens with a prompt to paste into your AI: "Install Jason by following https://get.jasonharness.ai/install. When it reports Ready, start its quick-start skill and take me to my first campaign. If anything stops you, ask me directly and tell me why." Those three lines are your yes to the install, so an agent given them installs without stopping to confirm each step; it asks you only for an act the install guide marks Ask first., or where its own checks stop it. An agent given only the link asks before the install, as before. The README's longer install text follows under "What the install does", and the handbook carries the same three lines. See the install guide.
• The quick-start skill. A new runtime skill, quick-start, takes a ready installation to a first campaign. It asks one question, what you sell and who should buy it, where a line about yourself and how you write is welcome and never required; it reads which provider your email and LinkedIn go through instead of asking you; it makes a draft of your first campaign and says the plan in one message, the goal, who it will look for, the channels and how it will write, ending "Say what to change, or say go." It reads which accounts are connected only after you say go, and a first message is never sent without your yes. An agent that finishes an install now hands over in one order: where your files are, what it ran and changed, what is not done now with its command (starting the runtime at logon, and skills for other agent hosts), and then the quick start, whose question comes in a message of its own. Installed Jason yourself? Ask your agent to start Jason's quick-start skill. See what the quick start does.
• The console in any browser tab. jason ui open now opens the same console the desktop's window draws, in place of the browser's older shell: the Dashboard, Needs you, People, Agents, Accounts, Performance, Activity, Work items, System, Settings and the search, everything that reads the runtime. Where the chat would be, the page says that the chat is part of Jason Desktop and links to the releases page; what only the desktop does is drawn off, with "This needs Jason Desktop." A tab the desktop opened, through Open in, then Browser, now shows the whole console too, with the chat as before: it sends only to a chat in Ask first or Plan only and never approves, and what only the desktop's window may do, the Demo | Live switch, the account acts of Connect and Accounts, the other access modes and the take-back of Full access, is drawn off with "Done in Jason Desktop's own window." Open in is not offered inside a tab. The runtime gains no route for either. See the browser UI's page.
• Your name and tone, in Settings. A section, Your name and tone, in two parts, each saved on its own: Who writes, your name, job title, company and the grammar forms for the writer, Neutral unless you choose another; and How you write, a few words and a formality. They are the named preferences sender.identity and tone_of_voice, saved through the Runtime API as you, so the section works in the desktop's window and in any tab alike. A save reads what is set again and changes only the fields you changed: a field set from a terminal in the meantime is kept, and so is everything the form does not show; with several senders set, the form edits the first and says so. Removing a value stays with jason preference unset. In the demo the section says it is set in Live.
• A one-time note on Start. In your own installation, once a chat exists and neither your name nor your tone is set, Start shows "Jason writes in your name." with Set preferences now, which opens that section, and Not now, which closes the note for good. Nothing else reminds you.
• The Dashboard counts over one period. A Period menu holds 7 days, 30 days, 3 months, 6 months, This year and Custom, with From and To; every tile and card counts over it, in calendar days of your time zone, ending now. The Dashboard opens on 30 days each time. Needs you counts what waits now, whatever the period.
• Interested, Meetings booked and Replies by category. Interested and Meetings booked now count the conversations whose replies the roles judged interested and meeting_booked, with a dash where none is, and a hover that says what each counts; Bounce rate still shows a dash. A new card, Replies by category, lists every category the roles' verdicts use, with its conversations and replies. These count judged replies, each in the period it arrived in: a reply no role has judged yet is not among them, so they are not the Replied tile's people.
• Daily trends. Beside Contacted, Replied, Interested, Meetings booked and each category, a small trend compares the last 24 hours with the 24 before them, whatever the period: a green "+N", a red "−N" or "±0", with a tooltip saying what is compared. Reply rate has none. Show daily trends in the Dashboard's header turns them off and on; the desktop remembers the choice, and a browser tab shows them and does not remember.
• jason reply count. A new read of the Runtime API, reply.count, and its verb, jason reply count [campaign-id...] --since <moment> --until <moment>: for each campaign named, or every campaign not archived, and in total, how many replies the roles judged under each category word, and in how many conversations. The window is held to each reply's own arrival, since included and until not, so a reply judged days later counts in the window it arrived in; one reply counts once, under the latest verdict recorded on it. --human shows one row per category for each campaign, and the total last. The desktop's chat runs it without a card in Ask first and Plan only, as a read. See the Runtime API.
• The demo opens on its sample in seconds. The sample is now made once, when the release is built, and every desktop package of the release carries it. The first start of the demo, and each Start the Demo Over, places it with jason import behind Preparing the demo…, in a few seconds where making it took over a minute. It is still made at the start when the archive is older than twenty-one days, by the moment the archive itself records; in a desktop built outside a release; and when the placing fails, after what it placed is taken away. See the desktop guide.

Upgrading from 0.40.0

Nothing stops, no setting is renamed and no database migration is added.

• The executable: jason update apply, or run the install line again. After it, jason skills update and jason ui install follow: the first brings this release's skills, the quick-start skill among them, and the second the console that jason ui open now opens.
• The packages: reply 0.15.1, journal-forwarder 1.3.0, ntfy 1.0.3, slack 1.0.0 and telegram 1.0.0, each the same as in 0.40.0, so there is nothing to replace with jason plugin install.
• The desktop is a separate install, as before: jason update does not install it. Download the installer or the disk image for your machine from this release, or let an installed desktop offer the update.
• Update the desktop and Jason together. The desktop places the page of its own version where the runtime is the one it carries, the Dashboard's switch for daily trends is remembered by this release's desktop, and the demo's prepared sample comes in this release's desktop package.
• jason ui open opens the console. A tab it opens, and a bookmark of the page, show the console in place of the browser's older shell, once this release's UI is placed.
• From 0.39.x or earlier, the notes of each release in between apply as well.

Known issues

The demo has limits: it is email only, with no LinkedIn channel; it raises no question; a person whose message waits for your approval never answers it, because a reply is attributed once, when it is stored; and no AI role runs in the demo's runtime, so no reply there is judged, and Interested, Meetings booked and Replies by category have nothing to count. The sample's story began when the release was built, with no past before it, so the Dashboard's 30 days hold it for thirty days after. Where the sample is placed, the replies the story wrote are already in when the demo opens; where it is made at the start instead, its story starts that day and its replies arrive within minutes. After that, a kept demo shows nothing new of the story until Start the Demo Over. In a placed demo the Dashboard's daily trends read ±0 at first, since nothing of the story falls in the last 24 hours.

Open in's Browser ha...

Jason 0.40.0

Jason 0.40.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.39.0

This release gives the desktop a top bar in your own installation and in the demo, with Open in, which opens a folder in an editor, a terminal or the file manager, continues a chat in a terminal and shows the desktop's chat in a browser tab; it rearranges the console around a new first screen, a sidebar with a Dashboard, a search box and a list of recent chats with a filter and a search; and a new installation now starts on the demo.

• A new installation opens on the demo. The first start of a new installation opens the demo, with nothing to click: the page shows at once, and the sample is made behind it under a small "Preparing the demo…" mark, which takes about a minute; what the sample already holds is shown while the rest arrives. Until it is ready, the Demo | Live switch, Start the Demo Over and Back to Your Own Installation wait, each saying "Available once the demo is ready." Live then sets up your own installation as a first start does. An installation that existed before, with a mode record or without, and one updated from an earlier version open where they did. Full access is still not offered in the demo.
• A top bar in both modes. A bar heads every screen, in your own installation and in the demo: a green dot and Live, or an amber dot, Demo data and "Nothing here is real or sent."; on its right, Open in and the Demo | Live switch, which is now the way into the demo and back. The start screen's "See Jason with sample data" line is gone; Start the Demo Over stays in the tray and the Jason menu.
• Open in. A split button in the top bar, in your own installation and in the demo, opens the folder in an installed editor (VS Code, Cursor, Antigravity, Windsurf, Zed), in Claude Code or Codex as a new session in a terminal, in a plain terminal, in the file manager, or copies its path. The place you used last is the default, else Claude Code. With a campaign's chat in front it is that campaign's folder, otherwise the harness root; in the demo, the demo's folders, and a terminal there works with the demo's data. Nothing is written into your folders for it, and the chat's AI cannot reach it. See the desktop guide.
• Continue this chat in a terminal. While a chat is in front, Open in's last group can hold Continue this chat in Claude Code (or in Codex): a new terminal in which that program continues its own conversation, the one the chat's turns ran in, at the chat's folder. Nothing is copied and no transcript is written. It is offered only when the chat's last turn ran on your own Claude Code or Codex sign-in, outside Full access. No entry is shown for a chat on a provider's key, for a chat whose last turn ran in Full access, or for a chat begun before this release, until it has had a turn. While a turn of the chat runs, it cannot be chosen. Beside it the menu says that the conversation continues under that program's own permission settings, that this window's permission cards do not follow it, and that this window does not show what happens there.
• The desktop's chat in a browser tab. Open in, then Browser, opens the desktop's chat in a tab of your browser, one more view onto the same chats the window shows, while the desktop runs: the list of conversations, a conversation and the box. A tab sends only to a chat in Ask first or Plan only, never answers a permission or plan card, and never changes a chat's mode or chooses Full access; a chat started from a tab starts in Ask first. The desktop's window stays the only place that approves. Only a tab the desktop opened shows the chat, paired once by a code in the link it opens; any other tab's Chat screen says how to open it from the desktop. The runtime gains no route for it.
• jason session open opens a folder, with no approval or question to start from. jason session open [--campaign <cmp_id> | --project <prj_id or slug> | --here] [--host <word> | --shell] [--resume <id>] opens your agent host, or with --shell the system's plain shell, in a new terminal at the campaign's folder, else its project's, else the harness root; with --here, at the folder the command runs in, as it is; with none of the three, at the project of the folder you run it in, else the harness root. The host is --host, else the named preference agent.interactive_host, else Claude Code, and no first input is sent to it. --resume <id> has the host continue its own conversation of that id, as claude --resume <id> or codex resume <id>; another host is refused with host_cannot_resume. The form with an approval or a question is unchanged. See the browser UI's page.
• A new first screen. Start carries Jason's mark over "Who do you want to reach?", and its box asks "Tell Jason what you sell and who you want to reach.", adding "A website link is enough to start." where the chosen AI host can open a page. Under the box sit an access button, for the mode new chats start with on this computer, a model button holding the model, the effort and the AI host, and a send arrow. The note under it, that this interface is optional, can be closed for each mode.
• The sidebar. New GTM agent is the main button and brings Start forward; its caret also offers New chat, a set-up chat as before, and Connect an account. Below it: Search, Feed, Dashboard, Needs you, with the number of approvals and questions waiting, People, Agents, Accounts, and More, which holds Performance, Activity, Work items, Connect and System. Settings sits alone at the foot. Every screen reached before still is.
• A Dashboard. A greeting, Review N waiting when something waits, and six tiles: Needs you, people contacted and people who replied over 30 days, with the reply rate, and Interested, Meetings booked and Bounce rate, which have no figures in Jason yet and show a dash and "no data yet", never a zero. Below them, the decisions waiting, the running agents with their people, contacted and replied over 30 days, and the Feed's latest lines. Every number is one the page already reads.
• Search, with Ctrl K or ⌘K. One box over the pages, Settings, New GTM agent and New chat, the agents and chats the console holds and, once you type, people; at most twelve rows, each opening where its sidebar row would.
• Recent. The chats under Recent each show a status dot, the number waiting on you and an age, ten at a time with Load more, and can be searched by title and filtered to Needs you, Live, Paused or Draft.

Fixed since 0.39.0

• A screen opened in the console's Page tab fills the panel. Performance, Work items, People, System, Accounts and Settings were drawn in a narrow column at the left of the panel; they now take its whole width.
• The demo's first opening no longer ends on "This browser isn't paired". The page now opens before the sample is made, so the link that pairs it no longer expires while the sample is made.
• A desktop quit while the demo's sample is made no longer leaves half a sample. The next demo start makes the sample whole by itself, where before it said the sample was not finished and pointed to Start the Demo Over.

Upgrading from 0.39.0

Nothing stops, no setting is renamed and no database migration is added.

• The executable: jason update apply, or run the install line again. After it, jason skills update and jason ui install follow.
• The packages: reply 0.15.1, journal-forwarder 1.3.0, ntfy 1.0.3, slack 1.0.0 and telegram 1.0.0, each the same as in 0.39.0, so there is nothing to replace with jason plugin install.
• The desktop is a separate install, as before: jason update does not install it. Download the installer or the disk image for your machine from this release, or let an installed desktop offer the update.
• Update the desktop and Jason together. The top bar, Open in and the chat in a tab are drawn by the page of this release, and the terminals the desktop opens run this release's jason session open.
• The runtime's page may now connect to loopback HTTP. Its Content-Security-Policy for every answer under /ui is default-src 'self'; connect-src 'self' http://127.0.0.1:*; frame-ancestors 'none'; base-uri 'none': besides its own origin, the page may open connections to any port on 127.0.0.1, and to no other host. That is how a tab reaches the desktop's chat.
• A bare jason session open, a usage error before, now opens your agent host at a folder, as above. A script that relied on the refusal gets a terminal instead.
• An existing installation opens as it did. Only a new installation's first start opens on the demo; an update from 0.39.0 changes nothing of where the desktop opens.
• From 0.38.x or earlier, the notes of each release in between apply as well.

Known issues

The demo is a first cut with limits: it is email only, with no LinkedIn channel; it raises no question; a person whose message waits for your approval never answers it, because a reply is attributed once, when it is stored; no AI role runs in the demo's runtime; and the sample starts today with no past, so there are no charts of earlier weeks. The replies the story wrote land over the twelve minutes after the sample is made, each shown within a minute of landing, when the demo's events are next read; after that, a kept demo shows nothing new until Start the demo over.

Open in's Browser hands the link to your browser as an argument. If the browser was not already running, its main
process keeps the link, with the pairing code in it, in its arguments for its whole life, wher...

Jason 0.39.0

Jason 0.39.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.38.0

This release adds a demo to the desktop: a second, real installation of Jason on invented people, so a person can see the product work before connecting anything of their own, with nothing sent to anyone.

• See Jason with sample data. The first screen of your own installation offers the demo in one line. Choosing it starts the desktop again on the demo, a data directory and a harness root of their own, each yours with -demo after the name (~/.jason-demo and ~/Jason-demo). Nothing of your installation is read, written or mixed in. A strip heads every screen of the demo, saying the data is sample and nothing is sent to anyone, with Demo and Live buttons, and Back to Your Own Installation in the tray and the Jason menu. Quitting a demo run, or switching to Live, stops the demo's runtime and never yours. The desktop guide says how.
• The demo is the product working. The desktop fills the demo installation through Jason's own command-line verbs: one project, four campaigns (two running, one paused, one a draft), fifty-four invented people at .example addresses, twenty-eight messages already approved and sent and ten waiting for your approval. An approval you give moves the work, the numbers are the runtime's own, the Feed moves because lines were written, and a few of the people written to answer over the first minutes. The runtime, the database, the verbs and the page are the ones you use; nothing in them exists for the demo.
• A provider plugin that reaches nobody. The sample runs through the demo provider, a plugin package like any other. Its manifest requests no program, no host and no variable, so by the plugin fence it can reach nothing outside its process, and a send made to it is answered as sent and goes to nobody. Its people, threads and replies are data inside the package, and it reports the written replies through the events contract. The desktop carries it and places it in the demo installation; no release publishes it, so jason plugin install demo has nothing to install. It is the plainest example of a provider package in the plugin guide.
• Start the Demo Over. In the demo's tray and Jason menu, beside the way back. It asks once, stops the demo's runtime and starts the desktop again; the next start removes the demo's two folders and makes the sample again, so the story moves from its start. What you did in the demo is gone, and your own installation is not touched.
• What is off in the demo. The demo has no real account, so the acts that connect or change one (signing in to Reply, adding, reconnecting, pausing, unblocking, limiting and deleting an account, connecting a notification channel, installing the Reply CLI) are off on the page, each card saying "Not in the demo: accounts are connected in your own installation." Updates, the start at logon, the jason command on the PATH and Remove What Jason Placed are off in a demo run too, each saying so.
• The chat works in the demo with the AI you connected, running jason against the demo installation, where it can do no harm to anybody; the chat's fence refuses your own installation's data directory and harness root whole. No AI role runs in the demo's runtime: the responder is off and the campaign manager keeps only the trigger it cannot do without, at its slowest cadence.
• The demo from a terminal. The demo installation is a real one: set JASON_DATA_DIR to its data directory and every jason verb reads and changes the demo. There is no verb of its own for it.
• Remove What Jason Placed and the Windows uninstall take the demo's two folders too, the demo's runtime stopped first; one that does not stop keeps both folders. They take off, too, any <folder>.removing-* copy a start over left beside either, when it carries the demo's mark. Each demo folder carries the mark .jason-demo-folder, and a folder of the same name without it is never used or removed. The demo's harness root is your harness root at the time the demo is set up, with -demo after it, so if you change Harness:Root later the removal takes off the new root's -demo folder and the old one stays behind.
• Full access is not offered in the demo, where the mode menu shows it off with "Not in the demo: Full access is for your own installation."

Fixed since 0.38.0

• The chat's fence reads a path in one spelling, and holds more of what it was meant to hold. These apply to your own installation's data directory as to the demo's folders, in every access mode unless said otherwise:
  • One canonical spelling of every fenced path before it is matched, in one function every check uses: home at any depth and in a file tool's path, file addresses, Windows device, network, stream and trailing-dot forms, the macOS data volume's prefix, and a relative path after a change of folder.
  • Network and device paths are refused for reads and walks as they already were for writes.
  • Links are judged by where they lead: a link's relative target is read from the folder the link is made in, and refused wherever that place is fenced. In Full access a command that gives a place another name (a symbolic or hard link, a junction, a substituted drive, a mount) is not run unasked, wherever it points, and "Always" never covers one.
  • The system's openers, launchers and schedulers are held, the programs that hand a file, an address or a command to the system's own opener, session, service manager or scheduler, or to a terminal, editor or window already running. In Full access they are not run unasked and "Always" never covers them, and a script the chat writes that starts one, or names a fenced place from its own folder, is refused; an edit is judged by the file as it would read after it.
  • A program's own folder option is followed (tar, git, make and the like), and a fenced place reached that way is refused; more archivers and copies that follow links are held.
  • A path the reader cannot see, such as a variable joined at run time, is not run unasked in Full access and is not covered by "Always".
  • In a demo run, your own data directory and harness root are refused whole in every mode, and Full access is not offered.

Upgrading from 0.38.0

Nothing stops, no setting is renamed and no database migration is added.

• The executable: jason update apply, or run the install line again. After it, jason skills update and jason ui install follow.
• The packages: reply 0.15.1, journal-forwarder 1.3.0, ntfy 1.0.3, slack 1.0.0 and telegram 1.0.0, each the same as in 0.38.0, so there is nothing to replace with jason plugin install.
• The desktop is a separate install, as before: jason update does not install it. Download the installer or the disk image for your machine from this release, or let an installed desktop offer the update.
• The demo is opt-in. A start is Live unless you chose the demo; an installation that never does has no demo folder and no changed behaviour.
• Update the desktop and Jason together. The offer and the strip are drawn by the page of this release; the page and the desktop that know the demo are the same release.
• From 0.37.x or earlier, the notes of each release in between apply as well.

Known issues

The demo is a first cut with limits: it is email only, with no LinkedIn channel; it raises no question; a person whose message waits for your approval never answers it, because a reply is attributed once, when it is stored; no AI role runs in the demo's runtime; and the sample starts today with no past, so there are no charts of earlier weeks. The replies the story wrote have all arrived in the first twelve minutes, after which a kept demo shows nothing new until Start the demo over.

The demo's first opening may show "This browser isn't paired"; choose View → Reload (Ctrl+R, or Command+R on macOS). Fixed in the next release.

Through Reply, a person the account already holds is never found by audience.search, however well they match, while
audience.preview counts and samples them, so a search can find fewer people than its preview said. A person the
campaign holds and Reply does not, one brought from a file say, can be found by a search again and is charged for; Jason
keeps them the one member they are.

A person the campaign holds from elsewhere, found by a search under another address, with no LinkedIn profile the two
share and no identifier of that provider pinned, becomes a second contact: a name never matches anybody.

Through Reply, a stop deletes the search's list: the people Reply found since the last read are charged, stay Reply's
contacts and never land in the campaign.

A search a person resumes at the provider after it ended stalled is not followed by the poll again; a read anybody
makes still lands its page: jason workitem create <campaign-id> --kind provider_op --operation audience.search_status --input '{"search":"<the search's work item>","limit":100}'.

The guard that keeps a route for a deferred send has two limits. A send with no moment known is not guarded, though its result says it can be cancelled: a provider answers a send it will make as soon as it can the same way as one it keeps queued for a sending schedule of its own. And a send still on its way when its route changes is not guarded: it can succeed under a plugin and account no route names any more, and it is logged only at the next start. If the route of such a send has moved, cancel it at the provider.

A thread is matched to its plugin, ...

Jason 0.38.0

Jason 0.38.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.37.0

This release lets one campaign send each channel through the plugin that suits it, and gives the desktop's chat and its page the controls people asked for: Full access answered once, Auto-edit, a plan card, an Accounts page, and an approval card that shows the message as written; and it makes the desktop's Feed say what was decided and what was done, finds people by what their custom fields hold, and lets a campaign's counts and its list of people leave archived people out, as its summary already could.

• A campaign can send email through one plugin and LinkedIn messages through another. A route may now name a channel under an operation, for message.send, conversation.reply and the sender.list filter: jason route set --campaign <id> --operation message.send --channel linkedin ..., or Channels under the operation's entry in Routes:Operations in settings.json. A channel route is looked for before the operation's own route, in this order: the campaign's channel route, its operation route, its default; then the global channel route, the global operation route, the global default. A campaign's own route or default therefore still hides a global channel route, and a call that names no channel never takes a channel route. What follows the send:
  • A cancel and a status read of a send go where the send ran, so a campaign with two plugins can cancel all its sends, not half.
  • Work on a thread goes where the campaign saw it. A read or a filing of a conversation goes to the plugin where the campaign saw the thread, and a reply routed to another plugin than the one that holds the thread is refused before anything runs, with thread_route_mismatch.
  • A route change may not strand a deferred send. route.set, route.unset and a reload that would take away the last route naming the plugin and account of a send the provider still holds for a later, known moment are refused with route_orphans_send, saying how many sends, their ids and the latest moment among them; cancel them with message.cancel, or change the route after that moment.
  • A channel route needs a plugin that reads events, since a reply to what a channel route sends reaches the campaign only through the events of the account it went from. A plugin that declares no contracts.events takes no channel route (route_channel_plugin_reads_no_events), and a package update that would drop contracts.events from a plugin a channel route names is refused whole.
  • Every surface shows them. jason route set, route unset, route resolve and operation describe take --channel; route list and the human views read a channel route as <operation> on <channel>; jason status and the System screen say how many of the routes go by channel, and jason doctor lists each channel route with its channel and gives no count. The routing guide, Routing, and the skills say how.
• Full access can be answered once for good. The confirmation offers Give full access this time, Always on this computer and Cancel; a checkbox, counted only with Always, also starts new chats in Full access. The desktop keeps the choice in a file of its own in the data directory, which a chat's commands are refused a write to, and it is taken back from the mode menu or the System screen. A chat already in Full access stays in it, and a chat reopened after a restart is in Ask first. The Feed is still refused Full access, and a held command's card still offers no Always. The choice exists for Claude Code only. It carries a consent number: a later release that widens what Full access reaches asks again.
• Auto-edit is a fourth access mode in the desktop's chat, between Plan only and Full access. It is Ask first, except that mkdir, touch, mv, cp, rm and rmdir run without a card when every path they name, and every path a copy or move writes, is inside the chat's own folder. Jason reads each command word by word and never hands this decision to the host's own accept-edits mode. A recursive or forced removal, a copy of a folder, a link that leads nowhere, a file in the chat folder named like one of the six programs, and anything outside the chat folder stay Ask first's card, and whatever Ask first refuses stays refused. Auto-edit is on Claude Code only, is not offered for the Feed, asks no confirmation, is never a default, and is gone when you close Jason. Its three limits are in the desktop guide.
• A plan card in Plan only. The answer a Plan only turn ends with is shown as a plan card with Approve and run and Keep planning. Approve and run switches the chat to Ask first and asks the AI to go ahead with that plan, never in Auto-edit or Full access, and sends nothing if the mode changed in between; Keep planning stays in Plan only. The card is live on the host that made the plan; on Codex it says the approved plan still only reads and that Claude Code carries it out. The Feed has no plan card.
• An Accounts page. One screen for what you have connected: in the desktop, the Reply card with its confirmed account acts (connect, reconnect, limits, pause and resume, unblock, delete), and for the notification channels whether each is on and what happened to its last notification, read only. In a browser the page says the provider's acts belong to the desktop.
• The approval card shows the message as written. For a parked email it shows From, To, Subject and the body as text; for a LinkedIn message, its text; for a template, the text and the example the runtime made for the person. A sentence under it says what it leaves out: the provider's signature and tracking.
• A parked message can be edited on its card, a first message or a reply: Edit message, then Save. Saving approves nothing; Jason asks again, about the new text, when it next takes the work, and the old approval can no longer be given. A card whose text changed elsewhere offers no Approve.
• The page says "agent" for a campaign with its chat, and the program that runs commands is "the AI". Only the page's words change; the CLI, the API, the skills and the documents keep "campaign".
• The desktop's first screen says the interface is optional, and an Alpha label sits beside the wordmark, in the browser and in the desktop alike.
• The model menu starts with Default (recommended), which passes no model and lets the host choose. Claude Code's entries read Opus (latest), Sonnet (latest), Haiku (latest) and Fable (latest), and a chat that chose a model before keeps it.
• What fences a command of a Codex chat, system by system.
  • On Windows a Codex chat needs Codex's elevated sandbox. The desktop checks, with no model, at the first Codex message of a run, that a command inside it is refused Jason's run file; Windows may ask for an administrator then, and answering No means chatting on Claude Code instead. Where the check fails, the chat says so and names codex sandbox setup --elevated, or Claude Code.
  • On macOS and Linux, Codex's read-only mode has no network by the vendor's own description, while the run file is readable there.
  • On every system a Codex command can read the rest of the data directory, a plugin's secret kept in settings.json among it, and the line under the Codex composer says so, system by system.
  • The desktop's window no longer keeps its pairing with the runtime on disk, on any system. At its first start this version ends every UI pairing and removes what earlier versions stored, so a browser you paired with jason ui open must be paired again once.
• The Feed shows what was decided: an approval approved or rejected, a question answered, and a campaign archived. The rows read "Approved", "Rejected", "A question was answered" and "Agent archived"; none of them waits on you, so none leads to Needs you. A row holds the ids, the kind and the moment, never who decided, the reason they gave or the option a question was answered with, and the AI that answers a Feed turn is handed the same and nothing more.
• The Feed shows a send and role work that finished. A message, a reply or an invitation the provider took reads "A message was sent or scheduled", "A reply was sent" or "An invitation was sent or scheduled"; the finished work of the planner, the researcher, the copywriter, the analyst and the deliverability specialist reads "A plan is ready", "Research finished", "Copy was written", "An analysis is ready" and "A deliverability check finished". The manager's and the responder's work already reaches the Feed as approvals, questions and sends, and the personalizer's and the critic's, which work message by message, are left out so they cannot fill the Feed; a role a person registered is never shown, and its name never reaches the Feed or a Feed turn. When the window loads, the desktop reads them back from the newest hundred finished work items, beside the Feed's other lines.
• People search finds a person by the value of a custom field, beside a name, a company, a title and a channel value: --query on jason contact list and jason campaign list-contacts, the API's contact.list and campaign.list_contacts, and the People page. Every text and every number in the custom fields is searched, at any depth: a text folded as the other terms are, so munchen finds München, and a number as it is written, so 1e5 is found by 1e5 and not by 100000. A field's name is not searched, so a field named industry holding retail is found by retail and not by industry. The provider's record of a person that an audience search keeps beside the custom fields, un...

Jason 0.37.0

Jason 0.37.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.36.0

The desktop's chat is fenced more tightly: it loads none of your own MCP servers or connectors, it runs Codex on Windows only where Codex's sandbox keeps Jason's data unreadable, and the CLI declines, inside a chat turn, the commands that give your word or change the installation.

• The chat loads none of your own MCP servers or connectors, on Claude Code and on Codex. Every MCP tool call the chat does make goes through its permission model. What you give up: the chat no longer reads your Codex config.toml, so a provider or a profile set there is not used; connect a key on the Connect card instead.
• On Windows, a Codex chat runs only where Codex's elevated sandbox keeps Jason's data unreadable. The desktop checks this itself, with no model, at the first Codex message of a run. Where the check fails, the chat says so and names codex sandbox setup --elevated, or Claude Code. On the one real machine checked so far, the elevated sandbox did not pass this check (see Known issues).
• The CLI refuses a person's word and changes to the installation inside a chat turn. Every desktop chat turn carries JASON_CONFINED, and under it the CLI refuses, before any request, the commands that give your word or change this installation, with one sentence and exit 1. This is a higher bar, not a boundary: a program that holds the run token can still act as you.
• The desktop's Reply card acts on accounts through reply-cli's own account verbs: connect, reconnect and the waiting list; an email account's daily limit; pause and resume of a LinkedIn account; unblock of a mailbox; and delete of either. Each change asks you first in a confirmation that names the account and the act; a connection link opens in your browser or is copied for you, and is never logged or kept. An agent's chat is refused these acts in every mode.
• A plugin's secret stays out of an AI role's agent. A secret given through the runtime's environment, by either of the two ways the plugin guide offers, no longer reaches the agent a role starts.
• Full access is a third mode in the desktop's chat, beside Ask first and Plan only, chosen from the menu beside the message box after a confirmation shown each time, with Cancel focused; Cancel keeps Ask first. In it the agent runs the commands Jason reads plainly without asking you. Anything else Jason holds as a card that waits thirty minutes and is then not run; what Ask first refuses is refused here too. Each grant works in a folder of its own, which Jason keeps for seven days after Full access ends and then removes. It needs Claude Code 2.1.322 or later and is Claude Code only: Codex keeps its read-only sandbox. It is not offered for the Feed, whose turns carry lines that others wrote.

Fixed since 0.36.0

• Appending to a file several plugins write at once no longer fails one of them while the others keep writing: the wait for the file counts as stuck only while nobody makes progress, and a holder that writes nothing still fails the append after ten seconds.
• A search the provider no longer has ends. A read or a stop of a search that fails search_not_found (the provider holds no search under the reference for the account the binding signs in as: deleted there, or that account changed) ends it cancelled, with its audience_search_ended line. In 0.36.0 such a search of an archived campaign was followed for good, and every route change that dropped the last route to its account was refused (route_orphans_search), removing the plugin included; in a campaign that runs it ended stalled only once the stall bound had passed.
• A second search waits behind one whose start answer was lost. A search item whose start may have acted, open again with no record of its search, now holds the campaign's next search as a running search does (search_unfinished, its workitem_waiting line naming it under behind_search); in 0.36.0 the next search was claimed and spent while the first might be running. Of two such searches the older goes first, and a search item that has ended holds nobody. Where a search whose start answer was lost ends for good, its hold on the campaign's next search is released while the provider may still be running it, so check the provider before the next search spends.
• An update between a lost answer and its repeat no longer refuses the repeat for good. A repeat of audience.search, campaign.enroll or campaign.activate after a lost answer is held to the plugin, the account and the input, no longer to the package's version, since each one's recovery read finds the earlier act at the account; jason update apply replaces an unedited package, and 0.36.0 then refused the repeat provider_answer_lost for good. The two sends the work item's key settles still go only under the package version that kept the key.

Upgrading from 0.36.0

Nothing stops: no setting is renamed, and no start refuses a setting 0.36.0 took. This release adds no database migration.

• The executable: jason update apply, or run the install line again. After it, jason skills update and jason ui install follow, and jason plugin install <id> --replace for each package you installed and did not edit.
• The packages: reply 0.15.1 (0.15.0 in 0.36.0), README and changelog only; journal-forwarder 1.3.0, ntfy 1.0.3, slack 1.0.0 and telegram 1.0.0 as in 0.36.0.
• The desktop is a separate install, as before: jason update does not install it. Download the installer or the disk image for your machine from this release, or let an installed desktop offer the update.
• On Windows, chat on Claude Code. The chat runs Codex only where Codex's elevated sandbox keeps Jason's data unreadable, and on the one real machine checked so far it did not, even once set up (see Known issues).
• The chat no longer uses the providers in Codex's config.toml. Connect a key on the Connect card.
• The desktop's Reply card needs reply-cli 0.21.0 or newer; below it, the card offers to update reply-cli where npm is installed.
• Claude Code older than 2.1.257 runs no chat turn; update Claude Code first.
• Codex older than 0.122.0 runs no chat turn; the chat says to update Codex.
• Going back: what jason update apply --version to an older release does to a newer plugin package, and how to load one again, is in Applying an older
  release.
• From 0.35.x or earlier, the notes of each release in between apply as well.

Known issues

Through Reply, a person the account already holds is never found by audience.search, however well they match, while
audience.preview counts and samples them, so a search can find fewer people than its preview said. A person the
campaign holds and Reply does not, one brought from a file say, can be found by a search again and is charged for; Jason
keeps them the one member they are.

A person the campaign holds from elsewhere, found by a search under another address, with no LinkedIn profile the two
share and no identifier of that provider pinned, becomes a second contact: a name never matches anybody.

Through Reply, a stop deletes the search's list: the people Reply found since the last read are charged, stay Reply's
contacts and never land in the campaign.

A search a person resumes at the provider after it ended stalled is not followed by the poll again; a read anybody
makes still lands its page: jason workitem create <campaign-id> --kind provider_op --operation audience.search_status --input '{"search":"<the search's work item>","limit":100}'.

A threshold set while nobody is on the campaign says at once that the reserve is low, since a count of nobody is under
any threshold, and wakes the manager for nothing. Set it once a search's people have landed.

Routes changed while the runtime was stopped, the settings file edited by hand say, are not refused at the next start,
which has no routes in force to keep, and a search whose start is under way when a route changes is not counted yet. A
search still followed whose account the routes then name nowhere is said in the log at warning, with its campaign; until
a route names that account again, its reads and its stop are refused and it goes on at the provider to its count.

A search the provider had already ended when its campaign was archived ends as it ended, and through Reply its list
stays at Reply with any people not yet read. A search whose start was under way when its campaign was archived has no
record yet, so nothing stops it: whether Reply took the start is read at Reply.

In Ask first, and in Plan only, the desktop's chat runs jason audience preview, jason audience filter-values and
jason audience availability without a card, as in 0.36.0. Each one asks the provider, and nothing in Jason limits how
often a chat, or any client holding the run token, makes them, or how many run at once: each starts a plugin process of
its own, so a typeahead asking a filter's values at every key starts one per key.

Codex in the desktop's chat reads and advises and acts through nothing: its sandbox is read-only.

On Windows the chat may decline Codex even after an administrator has set up Codex's elevated sandbox: that sandbox can still read part of Jason's data, a settings file in Jason's data folder among it, and on the one real machine checked it could. The chat then declines every Codex message until the desktop quits, and its sentence still names codex sandbox setup --elevated, which does not help there. Use Claude Code for the chat on Windows meanwhile; the next release changes the check.

The Windows check of Codex's sandbox has not been seen on a real machine without th...

Jason 0.36.0

Jason 0.36.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.35.0

A campaign can be filled from a description of who it is for. The description is written in the provider's own terms;
the provider says, for free, how many people it matches and shows a few of them; a search for some of them waits for a
person, then runs at the provider; and Jason follows the search by itself and makes the people it finds the campaign's
members as they arrive. A threshold says when the campaign is running low on people nobody has started on, and an
allowance a person gives lets the searches that top up an audience go without asking, up to a number of people. The
Reply package performs all of it through Reply's Live Data.

• An audience is described in the provider's terms. Six operations make a new family: audience.preview,
  audience.search, audience.search_status, audience.search_cancel, audience.filter_values and
  audience.availability, thirty operations in all. An audience's definition is the provider's own shape (which
  industries, which titles, which company sizes, as the provider names them), and a plugin that searches declares it as
  a schema. jason operation describe audience.search --campaign <campaign-id> prints what the plugin a campaign's
  searches are routed to takes, each filter with its description. See
  the audience family.
• A preview before anything is spent. jason audience preview --campaign <campaign-id> --definition '<json>'
  answers how many people and companies a definition matches and a sample of at most 25 of them, with no way to reach
  them; --audience <n> previews an audience the campaign already searched under. jason audience filter-values --campaign <campaign-id> --filter <name> --query <text> spells a filter's values as the provider does, and
  jason audience availability --campaign <campaign-id> says whether the account may search now. The three are the
  provider's reads, asked when a person or an agent asks, of the plugin and account the campaign's searches are routed
  to: nothing is recorded, journaled or pinned, a preview's definition is held to the plugin's schema first, a preview
  costs nothing by its contract, and a work item that names one of them is refused (on_request_only).
• A search is work that waits for a person. audience.search is a work item whose contract asks a person once:
  jason workitem create <campaign-id> --kind provider_op --operation audience.search --input '{"definition":{…},"count":25}' parks it for approval. It asks for 1 to 1000 people, one per company unless
  people_per_company says more, and names either a definition or, for a top-up, the number of an audience the campaign
  holds: {"audience":1,"count":25}. The claim holds the definition to the routed plugin's schema
  (definition_invalid), refuses a number the campaign holds no audience under (audience_unknown), and checks the
  search a status read or a stop names (search_unknown, search_reference_absent, search_route_mismatch); a read or
  a stop goes where the search ran, whatever its own operation is routed to now. A campaign runs one search at a time:
  a second waits, before anybody is asked to approve it, until the first has ended (search_unfinished, with a
  workitem_waiting line naming the search it waits behind). A search, an enrollment or an activation whose answer was
  lost is repeated only under the package and the account the attempt that may have spent ran under
  (provider_answer_lost). The claim now makes twenty-six checks, in one published order
  (routing).
• Audiences, numbered. The first search the claim lets through under a definition, to run or to wait for a person,
  makes the campaign an audience: an aud_ id, a number 1, 2, 3 within the campaign, and the definition as the claim
  held it. The same definition with its members in another order is the same audience, and a definition searched before
  finds its old number. The claim records the audience on the search under the context key context.audience, which no
  one else may write on a search. See
  the audiences.
• The people a search finds become the campaign's members, page by page. A search the provider takes ends its work
  item accepted. From then on a new step of the dispatcher's scan, the poll, reads it with audience.search_status
  every Dispatcher:SearchCadenceSeconds (300 by default), at once while the provider says more people are readable,
  and less often after reads that failed. Each page lands in the change set that ends its read: a person is found by the
  provider's identifier pinned at the plugin, then by each address, then by each LinkedIn profile; a person found nowhere
  becomes a contact, with what a contact has no field for under custom; and each becomes a member, except a person the
  campaign already holds, who stays the one member they are, and one removed from it, who stays removed. Membership is
  local: nothing is enrolled at the provider. In jason campaign list-contacts, a member a search brought in carries a
  source: the audience, as {id, number}, the search and when they landed. A search whose reads land nobody for
  Dispatcher:SearchStallSeconds (3600 by default) ends stalled and is read no more; one the provider holds, paused
  there, out of credits or at the plan's contact limit, is read every Dispatcher:SearchHeldCadenceSeconds (3600) and
  stalls only after Dispatcher:SearchHeldStallSeconds (a week). A stall bound below its cadence is refused at the
  start. The scan now runs twelve steps. See
  following a search.
• A search can be stopped. audience.search_cancel stops a search at the provider, and the people it already
  landed stay the campaign's. Like a pause or an opt-out it runs in a paused campaign, and like taking back a send it
  runs through a provider block; a stop that fails is notified as a protective action that failed. Archiving a campaign
  stops each of its searches still running: the poll makes one stop for each, the one work an archived campaign still
  runs, and the search ends cancelled, or as the provider had already ended it.
• A search keeps its account. A read or a stop of a search goes where the search ran, so a route change that would
  take the last of its campaign's routes and the global ones naming its plugin and account away from a search still
  followed is refused, naming the search: jason route set and jason route unset answer route_orphans_search, exit
  code 1, and change nothing, and a jason plugin reload carrying such a change keeps the routes in force and names the
  search under plugin_reload_rejected. Stop the search with audience.search_cancel, or let it end, then change the
  route; a change that leaves another of those routes naming the account goes through. An archived campaign's routes stay
  in force while a search of it is still followed, so the stop its archive made goes where the search ran; jason route list shows them until then. A start is not refused: a search still followed that the routes it starts with name
  nowhere is said in the log, with its campaign, then and at each later route change or reload while it lasts. See
  routing.
• The chronicle says how a search went. Five new kinds, written by the dispatcher, facts only:
  audience_people_landed, for each page that carried anybody; audience_search_held, once each time the provider
  holds a search; audience_search_ended, once per search, as finished, exhausted, stalled or cancelled; and
  audience_reserve_low and audience_reserve_recovered, below. audience_search_held, audience_search_ended and
  audience_reserve_low are new default triggers of the campaign manager.
• The reserve. jason campaign update <campaign-id> --audience-threshold 50 says how many people nobody has started
  on the campaign wants to keep, from 1 to 100000, and --clear audience_threshold takes it away. A step of the scan
  counts them whenever something that can change the number was written, and says once per crossing that the reserve
  fell under the threshold or recovered, so the manager is woken when the campaign runs low; it creates no work itself.
  The count is jason campaign summary's new, which now leaves out the work the runtime made about a person by itself,
  the read of a thread that moved and the responder it woke: a member whose only work is that is now counted as new.
  A person on the do-not-contact register lands and counts like any other.
  See the reserve.
• The allowance: a yes in advance for top-ups. A search spends the provider's credits, so a new audience's first
  search, its probe, always waits for a person. After it, a named person can let the searches under that audience go
  without asking until the people they ask for reach a ceiling, in the act of approving,
  jason approval approve <approval-id> --allow 250 --allow-per-search 25 --actor human:<name>, or on its own,
  jason approval set-standing <campaign-id> --operation audience.search --audience 1 --max-people 250 --max-per-search 25 --actor human:<name>; --allow-expires-at and --expires-at set an end, and `jason approval unset-standing
  <c...

Jason 0.35.0

Jason 0.35.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.34.0

Jason's desktop comes to Linux and becomes a place to work. It opens on a start screen. Its chat keeps one conversation per campaign, beside a Feed of what the runtime did, with the models and effort each host offers. The chat can work in Ask first or Plan only, searches the web and reads the hosts' documentation. The Reply card connects mailboxes and LinkedIn accounts by Reply's own link. The desktop opens jason-desktop:// links, offers a light and a dark theme, has a People page whose chips count where each person stands, takes off what it placed, and carries the new Jason AI mark.

The desktop on Linux

• Two packages. The desktop is published for Linux x64 as a deb and an AppImage, with the latest-linux.yml update feed. Each package carries the icon at the standard sizes, and each was read back and started sandboxed under a virtual display before it was published. The desktop refuses to start without Chromium's sandbox, on every platform.
• It behaves as a Linux application does. Logon goes through a systemd user unit and an XDG autostart entry; the jason command is put on the PATH, and the login shell's PATH is used; keys are kept only with a keyring; the AppImage keeps a copy of its jason under the data directory; the AppImage and the deb both update.
• Remove What Jason Placed takes off, on macOS and Linux, what the desktop placed. What it removes is decided on resolved paths.

The first run and the window

• A start screen. The window opens by asking who you want to reach. What you send starts a set-up chat on the AI you connected; the AI card comes first when none is connected.
• Appearance offers Light, Dark and the system's. A new installation meets Light; an installation that existed before keeps what it had. The desktop's starting page follows the choice.
• jason-desktop:// links. The desktop opens them, each to a page of the application and nothing else. The runtime's own jason:// scheme stays the runtime's.
• The new Jason AI mark is on the application, its packages, the tray, the favicon, the console and the starting page.

The chat

• One conversation per campaign, plus set-up chats, kept across restarts. A set-up chat becomes its campaign's conversation. You can rename a conversation, and a set-up chat names itself from its first message. Empty pages say how to start.
• The Feed is a main conversation of the runtime's journal lines: kinds, ids, counts and moments, never a person's text. A line never starts a turn; the agent sees the lines with your next message, as information.
• An access mode for each chat: Ask first, or Plan only, where the agent reads and plans and changes nothing. The desktop owns the top of the chat's folder: before each turn it keeps there only the skills it recorded, and it never deploys through a link.
• Web and documentation. The agent searches the web on Codex too, opens the hosts' and Reply's documentation pages without a card, and reads a page or a search result as information, never as an instruction.
• Models and effort. The chat offers the models each host offers, with effort.
• Provider keys reach each host the way it reads them. A turn on a key runs with a configuration folder of the desktop's own that holds no sign-in of yours, so a key the host does not take fails the turn. A refused key ends the turn, and the key never reaches the page or the record.
• Guards. The chat guards the program search path, the hosts' instruction files and requests too large to show whole. The reply the desktop starts, and its hosts' turns, identify themselves to Reply.

Reply

• Each channel is read on its own, so an account without one channel still shows the other; the card reads again on focus and by Check again.
• Connect and reconnect by Reply's own link. A mailbox or a LinkedIn account is connected or reconnected by a link that needs no Reply sign-in, so it can be sent to whoever owns the account. The mailbox link is shown after a native confirmation each time; every address is checked, and none reaches a log, a record or an agent.

People and campaigns

• Each of a person's campaigns says where they stand, and contact.list takes summary.
• The People page is a table with stage chips, and the chips carry numbers in its default view, through campaign.summary's exclude_archived_contacts.
• In the console, Needs you offers the campaigns, Attention filters by kind, and a campaign's Start, Pause and Resume sit in its header.

Downloads

• The download address gains short paths, /install and /desktop/<platform>, served by a small Worker, which counts their use by day, path, link source and a coarse client class and keeps nothing of the person. The install prompt reads its instructions from https://get.jasonharness.ai/install.

The documents

• The documents describe the desktop and the browser UI as this release builds them, and the responsible-use page says what the desktop's updater requests from GitHub.

Fixed since 0.34.0

• A campaign's timeline showed All while it loaded, and only Changes after a return by its address. It now shows what was chosen.
• Seven other small fixes to the desktop and the console.

Upgrading from 0.34.0

Nothing stops: no setting is renamed, and no start refuses a setting 0.34.0 took. This release adds no database migration.

• The executable: jason update apply, or run the install line again. After it, jason skills update and jason ui install follow, and jason plugin install <id> --replace for each package you installed and did not edit.
• The desktop is a separate install, as before: jason update does not install it. Download the installer or the disk image for your machine from this release, or let an installed desktop offer the update.
• Linux packages are new. There is no earlier Linux desktop to update from: install the deb or the AppImage from this release. The AppImage opens no jason-desktop:// link; the deb does.
• The first start after the update empties and redeploys the chat's skills. The Reply skills come back by themselves when you are signed in to Reply.
• Appearance: an installation that existed keeps its theme; a new one meets Light.
• Links: the desktop registers jason-desktop:// links, per user on Windows, through the application's bundle on macOS, and through the deb on Linux.
• The LinkedIn account links need Reply CLI 0.20.0 or later; the mailbox link works on 0.19.0.
• Claude Code older than 2.1.257 runs no chat turn; update Claude Code first.
• Going back: what jason update apply --version to an older release does to a newer plugin package, and how to load one again, is in Applying an older
  release.
• From 0.33.x or earlier, the notes of each release in between apply as well.

Known issues

Full access, the chat's third mode, is not in this version: the menu shows it disabled. Its code is in the release, switched off, because in two readings its refusals did not hold against commands spelled another way.

Codex in the desktop's chat reads and advises and acts through nothing: its sandbox is read-only.

Not yet seen on a real machine:

• The Linux packages by hand on Ubuntu 24.04: the tray on GNOME and KDE, the keyring, start at login across a sign-out, a deb update's password prompt, the AppImage replacing itself, Remove What Jason Placed, and a jason-desktop:// link clicked.
• The chat with real hosts and keys: a wrong key on each provider, which account pays when a plan is signed in, each effort level, and Plan only on a real Claude Code.
• Reply with a real account: the shared mailbox page, LinkedIn ids for Reconnect, and the confirmation box in a packaged build.
• On macOS, Remove What Jason Placed and the LaunchAgent; on every system, how the icon looks in the menu, the dock and the taskbar.

The AppImage refuses to start on a system that refuses its sandbox, with a sentence naming the deb; that refusal has not been seen either.

The Mac executable built for Intel is signed and notarized like the Apple silicon one, but the test suite does not run
on an Intel Mac, so that package is covered by what was built and signed and not by a run. Its jason moves only with
the desktop's own update, because jason update publishes no build for it.

The Windows installer ends the run, and installs nothing, when a process from the carried jason.exe still runs after
the stop; the next start of the application says nothing of it. Where PowerShell is not available the installer looks
for no process: a person is asked to stop the runtime, and an update goes on without a look.

The six libraries the Windows installer unpacks into its temporary folder (nsExec, nsis7z, SpiderBanner, StdUtils,
System and WinShell) carry no signature of ours. The installer's builder cannot sign them, and they are never installed.

The desktop's chat has been run in tests against stand-ins for Claude Code and Codex; no turn with a real host has been
watched through the desktop yet.

Work the desktop's chat queues for a role runs under that role's own execution profile, not behind the chat's cards.

The candidate 0.34.0-rc.1's desktop carries a jason without this refusal; jason update apply typed into it replaces
the file inside the application before any code of the new build runs. The new build finishes that update and refuses
the next one; the desktop's Check for Updates then brings the application to the same version. Such an update that
stopped at kept, before the new file was in place, leaves its record at ~/.jason/update/ledger.json, in the data
di...

Jason 0.34.0

Jason 0.34.0: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.33.0

Jason has a desktop application, a window onto the installation the jason command line already uses, with a chat
that drives Claude Code or Codex on your own machine; the browser UI is rebuilt on React and gains a person panel and a
campaign made of tabs; the runtime streams its journal, and jason journal watch follows it; and a fresh installation
is told what a provider plugin still needs.

The desktop

Jason Desktop is one more client of the installation, as the browser UI is. It finds the data directory as the CLI does
(JASON_DATA_DIR, otherwise ~/.jason), shows the UI the runtime serves at its loopback address, and changes the
installation only through jason verbs and through the settings file a person would edit. The runtime keeps no state
for it, and with no desktop installed nothing in the runtime differs.

• Three packages, signed. A release now publishes the desktop beside the executable: an installer for Windows x64,
  and a disk image and an update archive for each of Apple silicon and Intel Macs, with the two update feeds
  (latest.yml, latest-mac.yml) and the block maps. That is ten files more, so a release is twenty-four files.
  checksums.txt lists twenty of them: the three archives, the seven packages and the desktop's ten; it does not list
  manifest.json, itself or the two install scripts. manifest.json is unchanged, since it lists what jason update
  applies. On Windows the installer, its uninstaller and Jason.exe are signed, and so is the jason.exe the
  application carries, which is the release's own executable byte for byte. On macOS both packages are signed with a
  Developer ID, notarized and stapled. Each package carries one version, LICENSE and both notices.
• One installation. The desktop asks jason status whether a runtime is up and whether it is the same build, and
  starts one with jason runtime start only when none is, never as its own child. It deploys the role skills from the
  package it carries, and works in a chat folder of its own under <data>/desktop/chat. When the runtime is another
  version, its UI is loaded as it is and the window says the versions differ and names Check for Updates when the
  runtime runs from the jason the desktop carries, and jason update otherwise.
• A window that stays shut. The page gets window.jasonDesktop and nothing else, answered only from the top frame
  of a page at the runtime's origin. Navigation is locked to that origin; a link that leaves it opens in the system
  browser, and only when it is https:. Electron's own profile, storage and logs live under <data>/desktop/electron.
• Live chat. A person talks to Claude Code or Codex, which run on their own machine, and the host works the
  installation through the same jason command a person types. The words go to the host on standard input, never on its
  command line. For Claude Code the desktop decides what runs without asking, from an allow list of one rule for each of
  66 verbs and a deny list of the verbs a chat never runs (everything the CLI reserves for a person, export and
  import, suppression remove, route set, route unset, role set-profile, role add and project link, since a
  folder a project links becomes a working folder of every chat on its campaigns), and asks the person on a card for
  everything else. Every host's turn runs jason with JASON_CONFINED=1: a file a request carries comes on standard
  input, jason status --provider-cli runs a bare name found on the PATH only, and a command that names the variable
  is refused. Of the Reply CLI the chat may run reply auth status and reply account list and nothing else. A card's
  "Allow for this chat" shows exactly the command it covers and is never offered for a program that runs another, for a
  command with a word the shell would rewrite, or for one that names reply. The data directory is refused in every
  spelling the desktop can read. Codex, in this release, reads and advises with a read-only sandbox and no network, and
  acts through nothing.
• A chat that reads like one. The agent's answers are drawn as a fixed subset of Markdown (paragraphs, emphasis,
  code, lists, headings, quotes and simple tables; a link is shown as its text and address, never as a link). A message
  sent while a turn runs waits under the box and goes when the turn ends well; it can be taken back or replaced. The
  agent runs nothing in the background, and its steps are described in plain words, such as "Ran a jason command".
  The desktop writes its five rules for the agent as CLAUDE.md and AGENTS.md in the chat folder before every turn,
  so an edit to either does not last.
• Needs you, Campaigns, Activity. The console's home is a chat with dockable panels. Needs you says who an approval
  reaches, from which account and on which channel, and narrows to approvals or to questions; Campaigns and Activity
  follow the journal as it is written.
• Connect cards. Slack, Telegram, ntfy and the journal forwarder are configured in one act, which edits only that
  plugin's keys in <data>/config/settings.json, keeps everything else in the file, and refuses a file it cannot parse.
  Reply is signed in with reply auth login, or with a key on standard input, then installed and wired as the default
  route only where you have set none. A card says "configured" when the runtime accepted it, never "connected".
• Accounts and Disconnect. The Reply card groups the accounts the Reply CLI lists by channel, Email first, then
  LinkedIn, then any other channel under its own name, and shows each account's state as Reply itself reports it:
  Connected, Disconnected or Unknown for email; Enabled, Disabled, Signed out or Daily limit reached for LinkedIn. A
  state the card does not know is shown as Reply wrote it, as plain text. The card does not manage accounts: limits,
  signatures, pauses and an account's connection stay in Reply, and a link, "Manage accounts in Reply", opens Reply's
  web app in your browser. The Slack, Telegram and ntfy cards gain Disconnect, which asks once and then edits
  <data>/config/settings.json once: it removes that plugin's configuration and its notification entry, keeps the
  entry's Enabled: false where you had set it off, removes the Http grant that was derived from a server of the
  plugin's own, and keeps every other key, the rest of the plugin's grants and the installed package. It then reloads
  plugins. A settings file the desktop cannot parse is refused and left as it is. The journal forwarder has no
  Disconnect, since removing its receiver while its subscriptions stay granted would fail every line it is handed;
  ungranting it is its own act.
• The tray. It counts what waits on you, approvals and questions, read through the CLI at most every 30 seconds. A
  system notification carries the counts alone, never a name or a question's text. When the runtime comes back on
  another port, the window pairs again by itself. The tray never starts a runtime.
• Keys and logon. The View menu has New Chat and the six screens (CmdOrCtrl+N, CmdOrCtrl+1 to 6). "Open Jason
  at login" is the desktop's own and off by default; "Start the runtime at logon" is jason runtime autostart and
  nothing else.
• A jason command on the PATH, placed only on your word and only in an installed build. On macOS it is a wrapper
  in ~/.local/bin. On Windows it is jason.cmd and an extensionless wrapper for Git Bash in
  %LOCALAPPDATA%\Microsoft\WindowsApps, placed only when that folder is on your PATH. A jason that is not ours is
  never shadowed; the command is then named jason-desktop. jason.cmd passes its arguments through cmd.exe's parser a
  second time, so a script or an agent that passes JSON uses the executable's full path or Git Bash.
• Updates on your word, from this repository's stable releases only: a candidate's feed is never read. Installing
  one stops the runtime that the application's own jason runs, and a runtime of any other executable is never stopped.
  Before it replaces the application, the desktop copies the application as it was under
  <data>/desktop/rollback/<version>/, one copy at a time, named in the Jason menu. Nothing puts it back by itself;
  going back is quitting Jason and putting that folder in place of the installed application, which leaves your data as
  the newer version left it. See how the desktop
  updates.
• The Windows installer and uninstaller close the application and nothing else, by its exact path. A process running
  from the carried jason.exe is stopped through the application's own --stop-runtime start, which runs
  jason runtime stop, after your OK where you run the installer; one still found then ends the run before a file is
  replaced. Uninstalling takes off what the desktop placed, the PATH command, Open Jason at login and the runtime's
  logon start when it starts this application's jason, and names what it leaves: the data directory, the harness root
  and the updater's cache.
• Its log is <data>/logs/desktop-YYYYMMDD.jsonl, in the runtime log's shape and under its limits, and carries no
  token, path, command or word you typed. jason logs --source desktop reads it, and jason doctor carries a bounded
  tail of each log.

The browser UI

• React 18. The UI moves from Preact to React 18.3.1. Its screens, stores and API client behave as they did.
• A person panel. People opens a person beside the list, with tabs Details, Activity, Sequences, Messages (where a
  provider knows the person's threads), Next and Research. Details edits the record in...

Jason 0.34.0-rc.1

Jason 0.34.0-rc.1: the runtime, the CLI and the plugin host, one self-contained executable per platform, built
at this version and released only after its tests passed.

What is new since 0.33.0

Jason has a desktop application, a window onto the installation the jason command line already uses, with a chat
that drives Claude Code or Codex on your own machine; the browser UI is rebuilt on React and gains a person panel and a
campaign made of tabs; the runtime streams its journal, and jason journal watch follows it; and a fresh installation
is told what a provider plugin still needs.

The desktop

Jason Desktop is one more client of the installation, as the browser UI is. It finds the data directory as the CLI does
(JASON_DATA_DIR, otherwise ~/.jason), shows the UI the runtime serves at its loopback address, and changes the
installation only through jason verbs and through the settings file a person would edit. The runtime keeps no state
for it, and with no desktop installed nothing in the runtime differs.

• Three packages, signed. A release now publishes the desktop beside the executable: an installer for Windows x64,
  and a disk image and an update archive for each of Apple silicon and Intel Macs, with the two update feeds
  (latest.yml, latest-mac.yml) and the block maps. That is ten files more, so a release is twenty-four files.
  checksums.txt lists twenty of them: the three archives, the seven packages and the desktop's ten; it does not list
  manifest.json, itself or the two install scripts. manifest.json is unchanged, since it lists what jason update
  applies. On Windows the installer, its uninstaller and Jason.exe are signed, and so is the jason.exe the
  application carries, which is the release's own executable byte for byte. On macOS both packages are signed with a
  Developer ID, notarized and stapled. Each package carries one version, LICENSE and both notices.
• One installation. The desktop asks jason status whether a runtime is up and whether it is the same build, and
  starts one with jason runtime start only when none is, never as its own child. It deploys the role skills from the
  package it carries, and works in a chat folder of its own under <data>/desktop/chat. When the runtime is another
  version, its UI is loaded as it is and the window says the versions differ and names jason update.
• A window that stays shut. The page gets window.jasonDesktop and nothing else, answered only from the top frame
  of a page at the runtime's origin. Navigation is locked to that origin; a link that leaves it opens in the system
  browser, and only when it is https:. Electron's own profile, storage and logs live under <data>/desktop/electron.
• Live chat. A person talks to Claude Code or Codex, which run on their own machine, and the host works the
  installation through the same jason command a person types. The words go to the host on standard input, never on
  its command line. For Claude Code the desktop decides what runs without asking, from an allow list of one rule for
  each of 67 verbs and a deny list of the verbs a chat never runs (everything the CLI reserves for a person,
  export and import, suppression remove, route set, route unset, role set-profile and role add), and
  asks the person on a card for everything else. Of the Reply CLI the chat may run reply auth status and
  reply account list and nothing else. A card's "Allow for this chat" shows exactly the command it covers and is
  never offered for a program that runs another, for a command with a word the shell would rewrite, or for one that
  names reply. The data directory is refused in every spelling the desktop can read. Codex, in this release, reads
  and advises with a read-only sandbox and no network, and acts through nothing.
• A chat that reads like one. The agent's answers are drawn as a fixed subset of Markdown (paragraphs, emphasis,
  code, lists, headings, quotes and simple tables; a link is shown as its text and address, never as a link). A message
  sent while a turn runs waits under the box and goes when the turn ends well; it can be taken back or replaced. The
  agent runs nothing in the background, and its steps are described in plain words, such as "Ran a jason command".
  The desktop writes its five rules for the agent as CLAUDE.md and AGENTS.md in the chat folder before every turn,
  so an edit to either does not last.
• Needs you, Campaigns, Activity. The console's home is a chat with dockable panels. Needs you says who an approval
  reaches, from which account and on which channel, and narrows to approvals or to questions; Campaigns and Activity
  follow the journal as it is written.
• Connect cards. Slack, Telegram, ntfy and the journal forwarder are configured in one act, which edits only that
  plugin's keys in <data>/config/settings.json, keeps everything else in the file, and refuses a file it cannot parse.
  Reply is signed in with reply auth login, or with a key on standard input, then installed and wired as the default
  route only where you have set none. A card says "configured" when the runtime accepted it, never "connected".
• The tray. It counts what waits on you, approvals and questions, read through the CLI at most every 30 seconds. A
  system notification carries the counts alone, never a name or a question's text. When the runtime comes back on
  another port, the window pairs again by itself. The tray never starts a runtime.
• Keys and logon. The View menu has New Chat and the six screens (CmdOrCtrl+N, CmdOrCtrl+1 to 6). "Open Jason
  at login" is the desktop's own and off by default; "Start the runtime at logon" is jason runtime autostart and
  nothing else.
• A jason command on the PATH, placed only on your word and only in an installed build. On macOS it is a wrapper
  in ~/.local/bin. On Windows it is jason.cmd and an extensionless wrapper for Git Bash in
  %LOCALAPPDATA%\Microsoft\WindowsApps, placed only when that folder is on your PATH. A jason that is not ours is
  never shadowed; the command is then named jason-desktop. jason.cmd passes its arguments through cmd.exe's parser a
  second time, so a script or an agent that passes JSON uses the executable's full path or Git Bash.
• Updates on your word, from this repository's stable releases only: a candidate's feed is never read. Installing
  one stops the runtime that the application's own jason runs, and a runtime of any other executable is never stopped.
  Before it replaces the application, the desktop copies the application as it was under
  <data>/desktop/rollback/<version>/, one copy at a time, named in the Jason menu. Nothing puts it back by itself;
  going back is quitting Jason and putting that folder in place of the installed application, which leaves your data as
  the newer version left it. See how the desktop
  updates.
• The Windows installer and uninstaller close the application and nothing else, by its exact path. A process running
  from the carried jason.exe is stopped through the application's own --stop-runtime start, which runs
  jason runtime stop, after your OK where you run the installer; one still found then ends the run before a file is
  replaced. Uninstalling takes off what the desktop placed, the PATH command, Open Jason at login and the runtime's
  logon start when it starts this application's jason, and names what it leaves: the data directory, the harness root
  and the updater's cache.
• Its log is <data>/logs/desktop-YYYYMMDD.jsonl, in the runtime log's shape and under its limits, and carries no
  token, path, command or word you typed. jason logs --source desktop reads it, and jason doctor carries a bounded
  tail of each log.

The browser UI

• React 18. The UI moves from Preact to React 18.3.1. Its screens, stores and API client behave as they did.
• A person panel. People opens a person beside the list, with tabs Details, Activity, Sequences, Messages (where a
  provider knows the person's threads), Next and Research. Details edits the record in place and can queue the change
  for the provider; it also puts the person on or off Jason's own do-not-contact register, address by address or as a
  whole, asking a reason for taking one off. Sequences excludes a person from a campaign or moves them to another one.
  Research lists what the researcher role found and can ask it for more.
• A campaign is a set of tabs: Sequence, People, Inbox, Results and Settings. Sequence is where a campaign opens and
  ends with what happened. Inbox shows the latest replies Jason observed, each at the moment the provider says the
  thread moved. Results shows four figures as the runtime counts them. Settings holds the record and the moves its
  status allows: Pause, Resume and Start. An address that named Details opens Settings, and any other tab that is gone
  opens Sequence.
• Needs you and Attention show the person an approval reaches, the account it goes from and its channel, and say
  plainly when nothing waits.
• Settings and Ukrainian. The browser gains a Settings screen for the theme and the language, English or Ukrainian,
  kept in the browser's own storage. A Chat screen says the chat is part of the desktop and links to the releases page.

For a person who scripts the CLI

• jason journal watch [--after <id>] [--human] follows the journal until interrupted, one line per frame in the
  shape journal.list answers, over a WebSocket at GET /v1/journal.stream, the one GET under /v1/. Without
  --after it starts with the next line committed; with it, after that id. A resume may send a line once more and never
  skips one, so drop a repeat by its id. Exit 0 on an interrupt, 1 when the runtime refuses the request, 3 wh...