Docs

What’s new.

Two lists. The first is read from GitHub as you open this page: the pull requests merged lately in the public repositories, this site’s among them, newest first. The second is each product’s own list of changes, from the statement it ships with, as of this copy, written 2026-10-18 07:40 UTC.

Merged lately

Asking GitHub for the latest merged pull requests…

    By product

    Symphony GitHub Apps

    1. Version 16 adds the Tokens page’s tiles: the settings each token’s tile writes to the variable SYMPHONY_CLAUDE_SETTINGS and its label variable, and the X that deletes a slot’s secret, label, settings and place in SYMPHONY_CLAUDE_ACCOUNTS. Nothing the developer receives or keeps changed.
    2. Version 15 says that the Tokens page’s “Add a Claude account” starts the workflow Token on the repository in place of “Add with one press”, which made a Codespace: the issue it opens, the sign-in link, the code and the sealed token on that issue, the page saving the sealed box as the next slot and as CLAUDE_CODE_OAUTH_TOKEN while that is not set, and the link to the Claude GitHub App’s install page. The page no longer makes a Codespace or saves a Codespaces secret, and the permissions Codespaces and Codespaces user secrets go unused. Nothing the developer receives or keeps changed.
    3. Version 14 adds Symphony Setup’s organization permission Administration (read and write), used only to allow “Allow GitHub Actions to create and approve pull requests” for an organization whose policy holds it off, so the sixth setting needs no step by hand there; the run reads the organization’s workflow permissions to leave the token’s default permissions as they were. Nothing the developer receives or keeps changed.
    Earlier changes (12)
    1. Version 13 adds SymphonyBoard’s repository permission Actions (read and write), which the control panel’s buttons that start a workflow run by hand, and its reads of the runs, use as you. What the pages do is unchanged, and nothing the developer receives or keeps changed.
    2. Version 12 adds the Tokens page’s “Add with one press”: SymphonyBoard’s repository permission Codespaces and account permission Codespaces user secrets; the Codespace the page makes and deletes on your press; the page’s GitHub token handed to it as your Codespaces secret SYMPHONY_GITHUB_HANDOVER, seen by your own Codespaces on that repository alone and deleted once the slot is saved; the Claude token going from claude to GitHub inside the Codespace, never to the page; and the page’s reads of the organization’s secret names while it waits. Nothing the developer receives or keeps changed.
    3. Version 11 adds the control panel’s Assistant section: an issue of yours, Assistant: <your login> labelled assistant, that the page opens once per repository on your press, each question a comment of yours on it that mentions @claude and ends with a short block of the page’s state, the answer the repository’s Claude workflow writes there, reading only, the page’s reads of that issue’s comments every few seconds while it waits, its reads of whether you may write to the repository and of the assistant’s file on the default branch, and the number of that issue kept in your browser for each repository. Nothing the developer receives or keeps changed.
    4. Version 10 adds SymphonyBoard’s two organization permissions, Secrets and Variables (read and write), and the Tokens page’s “Add or renew a slot”, which seals a Claude token you paste in your browser and saves it, as you, as one of your organization’s Actions secrets, with its label and the list of slots as variables. Nothing the developer receives or keeps changed.
    5. Version 9 says where a sign-in for one tab keeps its refresh token: in the open page’s memory alone, never in the browser’s storage, so that the renewals end once that page is closed, reloaded or replaced by another page, and the sign-in then ends with its eight-hour token; that the tab’s own storage comes back with a tab the browser reopens or restores; that a pasted token is asked about at GitHub before the page keeps it; and that a sign-in’s token that a new sign-in or an accepted pasted token replaces is revoked through the service, as “Forget the token” revokes one. Nothing the developer receives or keeps changed.
    6. Version 8 adds the control panel and the cost page of the developer’s site, as the section of that name says: pages that work in your browser with a GitHub token you give them, talk to GitHub’s API as you, and, with “Sign in with GitHub”, send GitHub’s one-time code to a stateless service of the developer’s on Cloudflare that answers with the token and a refresh token and keeps nothing. Nothing the developer receives or keeps changed.
    7. Version 7 removes the sweep: no workflow on the front door lists SymphonyBoard’s installations every ten minutes and reads each repository they reach to decide whether to offer an adoption, since installing the App alone is no longer a request, the install sending you to the form, where the press is; the run reads an installation only when a form carries its number, as the adoption section now says, and the collector’s daily read of the branch metrics is as it was. With the sweep go two things the run did on its path only: it no longer reads a repository’s direct collaborators to find an administrator, since every request names the person who asked, and it no longer opens an issue in your repository when it could not open its pull request, since the form’s own issue is answered instead. Nothing the developer receives or keeps changed.
    8. Version 6 says that the run, asked for a repository with no commit yet, first makes its first commit, as GitHub’s own “Add a README file” does: a README.md holding the repository’s name, on the default branch, which Contents write allows; that it reads whether such a repository has any branch at all; that closing the pull request leaves that README; and, as it did already, that when the form carries an installation’s number the run asks of each repository both Apps reach what it asks of the one it adopts. Nothing the developer receives or keeps changed.
    9. Version 5 says that the run also reads the two switches under their names before the rename to Symphony, .github/sdlc-adopt and .github/sdlc-metrics; that an adoption never turns on a switch of the repository’s own that says off already, under either name, and brings nothing that shares where it cannot write the switch; that a repository adopted before the rename turns sharing off in .github/sdlc-metrics, the switch its workflow reads; and that Symphony Setup also uninstalls itself after a request refused because the repository is adopted already. Nothing the developer receives or keeps changed.
    10. Version 4 adds the sixth setting Symphony Setup applies: in a repository that takes the whole template, it ticks “Allow GitHub Actions to create and approve pull requests” where your organization and its enterprise allow it. It also names what the run reads to leave your settings as they are: the repository’s rulesets, its topics and its workflow permissions for GitHub Actions. Nothing the developer receives or keeps changed.
    11. Version 3 adds to METRICS.json what the work cost, as the section on field metrics describes: the tokens Claude used, by kind and by model family, their price at Anthropic’s API list prices and the date of that list, the seconds Claude was at work, the counts and rates per merge they are set against, and the comparison of work done alone with work done in parallel; and it says which records in your repository the workflow reads to make them, and that the switch stops those records too. Nothing else changed.
    12. Version 2 adds to METRICS.json and JUDGE.json the counts of how the work ran in parallel that the section on field metrics describes, and to JUDGE.json how many of its conversations had two or more people, the number of days it covered and any limit it ran under. It also says what the workflow reads to make METRICS.json, and names what the two files held already and version 1 left out: the time each was made, the number of days METRICS.json covers and the short id of the protocol’s commit, and, in JUDGE.json, how many conversations were judged, the totals of the failure types’ three groups, the model, the version of the prompt and the word that names its schema. Nothing else changed.

    From its privacy statement, version 16.

    Symphony for Chrome

    1. Version 6 (extension 1.4.1) says how the popup’s links open.
    2. Version 5 (extension 1.4.0) says that the step from Symphony Setup’s install page covers its permissions page too, when it arrived without the repository.
    3. Version 4 (extension 1.3.0) added the third case in which the page is moved, from the second App’s account-picker page, where the first App’s install now lands, to its install page with the repository preselected, and that page’s address among what is read.
    Earlier changes (2)
    1. Version 3 (extension 1.2.0) added the About sidebar’s topic links among what is read, for the one topic that marks an adopted repository.
    2. Version 2 (extension 1.1.0) added the second note, the second banner, the repository’s tags and the form page’s query string among what is read, and the two cases in which the page is moved; version 1 shipped with extension 1.0.0.

    From its privacy statement, version 6.

    Beethoven

    1. Version 17 (2026-10-18, Beethoven 22.0.0): For your lab lead in Settings gains Connect GitHub Actions and Remove, which type one line each in the portal’s shell to set up or take out the grid’s ssh gate for one GitHub repository from the lab lead’s own copy of hpcworker, as the section on your cluster account says. Nothing is stored and nothing reaches Licensor. Licensor treats this change as not material to the agreement, since nothing is typed unless a lab lead presses one of the two buttons, so the agreement stays at version 15 and an acceptance of it stays in force. Version 16’s other terms are unchanged.
    2. Version 16 (2026-10-16, Beethoven 21.0.0): Settings takes the address of a project of yours on claude.ai, kept in storage.local with your other preferences until you clear it. With one given, the page Beethoven opens when a worker you started is ready, if you kept that on, and the page Open my project opens, is that project’s page in place of your session’s link, since a project takes up your worker only when you ask for the work there; New session and Copy link keep your session’s link. Beethoven makes no request to claude.ai for it and never reads the page; it notes the project’s tab it opened, as it notes your claude.ai tab, so it can bring it forward. The card that offers Settings for the address is noted with the other one-time tips. Version 15’s other terms are unchanged.
    3. Version 15 (2026-10-13, Beethoven 20.0.0): Beethoven’s listing on the Chrome Web Store is public: installing it needs no invitation, and your approval still decides whether it works. The request page no longer asks for a Google account, since no invitation is sent; a Google account given earlier stays in the access record and is no longer used. Version 14’s other terms are unchanged.
    Earlier changes (13)
    1. Version 14 (2026-10-11, drafted for Beethoven 20.0.0 and replaced by version 15 before 20.0.0 shipped): your approval works on every installation of your own: a second computer, browser profile or reinstall is approved at its first check instead of refused, Licensor’s service keeps the list of the ten most recent installations your account asked from and tells Licensor of a new one by e-mail with a link to withdraw the approval and none to move it; an installation still serves one account. Version 13’s other terms are unchanged.
    2. Version 13 (2026-10-09, Beethoven 19.0.0): Beethoven signs in to your portal for you. In Chrome, when your portal asks for a sign-in, the panel shows Beethoven’s own sign-in sheet for your account name and cluster password, and the extension answers your portal’s request for a sign-in from its background, with no tab, under the webRequest and webRequestAuthProvider permissions, which it now requests: only for its own reading of your portal’s dashboard, at most once per check, and never for a tab, a proxy, another website or another realm. It sends a password your portal turns down at most once, and that refusal stops every sign-in it makes by itself until you type the password again. Saving the password is optional and off unless you tick Remember it on this computer; a saved password is kept only encrypted, in the extension’s database in this browser profile, under a key derived from what a passkey releases (Windows Hello, Touch ID or your screen lock, named with your account name followed by “(grid)”); what the passkey releases stays in memory only, from when you unlock it until the browser closes or Beethoven updates or reloads; a password not saved is kept in memory for one sign-in and at most two minutes. New in your browser: the saved sign-in, its note, the note that a passkey could not lock a password, the unlocked secret, the typed password for one sign-in and the outcomes of the last tries (the table). Forget beside Grid sign-in in Settings, Disconnect and changing to another portal delete them. Chrome keeps a password that worked in memory until it closes and uses it for your portal tabs too. Use Chrome’s sign-in box instead keeps the way of 18.0.0, which is also the only way where the extension cannot answer a request for a sign-in. The statement now tells the old passkey of 12.0.0 to 15.0.0 apart from the new one. Nothing new reaches Licensor.
    3. Version 12 (2026-10-08, Beethoven 16.0.0): the direct way of versions 12.0.0 to 15.0.0 is removed whole. The extension no longer reaches your cluster over ssh, has no Bridge, no sign-in sheet, no key in your browser, no passkey, no Forget this computer, no phone route and no relay, holds no nativeMessaging permission, and never asks for your cluster password or verification code; it reaches your cluster only through your university’s Open OnDemand portal, behind your university’s VPN where it requires one, as versions up to 11.0.0 did. On its first run after the update it deletes from your browser what the direct way kept there, the key unread, and keeps one note where that version recorded that it had added a line to your cluster account, which Settings show once, with Forget; the Bridge on your computer, that line and a passkey are outside the browser and stay until you remove them, as the new section What an earlier version may have left says. New on your device: a press you made while the grid was out of reach waits and goes ahead by itself once the grid answers, with the extension asking your portal’s address whether it answers every three seconds while a page of Beethoven’s is open and once a minute while none is; Keep my worker running also starts a worker again that ended, at most three times in a row; and the screen that asks you to turn on your VPN links your university’s own page about it. The sections on the Bridge, the ssh sign-in, the relays and the pilot app, and on what your university sees on the ssh path, are gone with them. Nothing new reaches Licensor.
    4. Version 11 (2026-10-04, Beethoven 15.0.0): on Windows and on a Mac the Bridge is now a compiled program of Licensor’s, offered from inside the extension as a signed installer that installs into your own account without administrator rights: on Windows a Windows Installer file signed by Licensor, removed from Settings, Apps; on a Mac an installer package signed by Licensor and notarized by Apple, removed with the uninstaller beside the Bridge. On Linux the Bridge is the script it was. A Bridge installed from a zip file with an earlier version keeps working until you remove it with the uninstaller beside it. When you open a signed installer, your system may check its signature with Apple or Microsoft; that is your system’s own behaviour and tells Licensor nothing. The Bridge does what it did: it reaches only your cluster’s ssh port, carries the encrypted connection and keeps nothing. Nothing new reaches Licensor.
    5. Version 10 (2026-10-02, Beethoven 12.0.0): the extension now tries the ssh path first: an ssh connection to your cluster’s login node, with no VPN, carried by the Bridge, a small helper program that ships inside the extension and that you install once on your computer, without administrator rights; it reaches only your cluster’s ssh port and keeps nothing. The first time, you sign in on the extension’s own sign-in sheet with your account name, password and verification code, which go only to your cluster, inside the encrypted connection, and are never stored; the extension then keeps a key in your browser that no script can copy out, and adds one restricted line to your cluster account that lets that key run only a short list of commands and never sign a worker in to Claude. Protecting that key with a passkey (Windows Hello or Touch ID) is optional and off unless you turn it on. Forget this computer removes the key and the line. Where your cluster has no verification code for you, the extension shows how to set one up yourself, on a computer or on your phone, with QR codes drawn on your device. A relay is not used unless your university’s site profile names one, and this statement would name it first; the pilot app is given only to a student who asks. Without the Bridge the extension works through your portal, as before. The approval check is unchanged and is sent only after your cluster accepts your sign-in. Nothing new reaches Licensor.
    6. Version 9 (2026-10-01, Beethoven 11.0.0): the agreement is accepted on a welcome page with one box and one button, with no typed name; the acceptance record now holds the summary and the sentence shown, whether you opened, scrolled to the end of, saved or printed the full text, and, once your portal first shows it, your account name. The extension now reaches your portal from its own background, on the sign-in your browser keeps, and opens a portal tab only for you to sign in, closing it afterwards, or, on a portal that does not share its sign-in, in the background for one action; after you agree, and before you sign in, it checks whether your portal answers, with requests that carry no sign-in. One command starts your worker and, when needed, the Claude sign-in, and writes your Remote Control answer; the framework keeps a plain-words progress log for each worker. Where the portal’s shell asks for a password, a one-time step makes a key in your cluster account that only your institution’s Open OnDemand server can use; you type your password into the portal’s own terminal page, and the extension never sees it and keeps nothing about the key. New on your device: your worker’s last known state and link, how the extension reaches your portal, your last five waits, the tour and the one-time tips seen, an activity list for Show log, the tabs it opened itself, and your appearance choice; the note of the tab the toolbar button was clicked from is gone, with the activeTab permission. The QR code for your phone and the tour are drawn on your device. The statement now names what the access service keeps from the checks (how many, and the reason given with a no), the reviewers’ mock account, and that the list of approved accounts is not published, and says “no site permission on claude.ai” where it said “no access”. Nothing new reaches Licensor.
    7. Version 8 (2026-09-30, Beethoven 8.0.0): the extension no longer carries the framework’s scripts and never copies them into your account. It works only with the one shared copy your university’s lab keeps on the cluster; where there is none, or your account cannot use it, it says so and names whom to ask, and uploads nothing. The note of the install it ran no longer counts uploaded files. One approved account, one installation: the approval check now also sends the random installation identifier the extension already kept, and the service binds an approval to the first installation that asks, refuses any other until Licensor moves the approval, refuses that installation for any other account, and keeps what One approved account, one installation says. Beethoven is offered only through a private listing on the Chrome Web Store. The request page now also asks for the Google account that receives the invitation to that listing, takes an optional CV (deleted twelve months after the decision), and may ask you to confirm your university mailbox.
    8. Version 7 (2026-09-29, Beethoven 7.0.0): the product has a new name, Beethoven, and new addresses. Its pages, the support page and the request page are under https://openspineconsortium.com/beethoven/; the two daily files are https://openspineconsortium.com/beethoven/services.json and https://openspineconsortium.com/beethoven/killlist.json; the access service answers at https://beethoven-access.openspineconsortium.workers.dev, a second name for the same service, which keeps the same records. The request page now also tells the service which product’s page a request was sent from. Nothing about the data changed: the extension keeps, sends and receives the same items as under version 6, and Licensor records the same.
    9. Version 6 (2026-09-29, extension 5.0.0): where your institution’s lab keeps one shared, read-only copy of the cluster-side scripts, the extension no longer copies them into your account; it writes a small launcher, a one-line marker naming the lab’s copy and your profile, and reads that copy’s version file through your portal. Nothing new leaves your device and nothing new reaches Licensor. The install note the extension keeps is also written when you press “Set up the cluster again” under Details.
    10. Version 5 (2026-09-29, extension 4.0.0): there are no license keys any more, and nothing to type or paste. Your own sign-in to your portal identifies you, by the account name the portal’s dashboard shows; the extension confirms with Licensor’s access service that this account is approved when you connect, when you click the icon and about once a day, and that check is now the one request that carries anything about you (the account name, the portal’s hostname, the product and its version; Licensor records those with the time, a salted hash of the network address and the answer). The daily list withdraws versions only; the extension also reads a daily services file for the service’s address. The table rows for the key and the identifier are replaced by the account name and the last answer; the Ask for access button, which carries your account name in the page’s address, is named. Nothing else changed.
    11. Version 4 (2026-09-29): the statement now describes the software as built. Earlier versions described an activation request and optional error reports; the extension has neither (there is no code for them and no address to send them to), so the sections that described them are removed and the section “What Licensor receives” names the one request the extension makes to Licensor, the daily withdrawn-keys list. The record Licensor keeps when it issues a key is named for what it is. Nothing new leaves your device; less was ever leaving it than the earlier text said.
    12. Version 3 (2026-09-29): the extension now starts the Claude sign-in sitting for you and takes the pasted code in its own panel (the section “What happens when you sign in to Claude” is new); your statement about a worker’s workspace is kept per workspace in the browser instead of per browser session, and now includes your answer to Claude Code’s Remote Control question, which the extension records in one marker file in your cluster account; the notes the extension keeps so its automatic steps do not repeat (the last sign-in it saw, the links it opened, the check job it submitted, the install it ran) are listed; the session-state row names everything the run record holds, including the last 4,000 characters of the worker’s own log; the preference “open claude.ai when my worker connects” is added; the audit-log row says what it never holds. Nothing new leaves your device or your accounts.
    13. Version 2 (2026-09-29): added the checklist tick, the start-by-itself preference and the session’s claude.ai link to the table of what stays in your browser, and named the withdrawn-keys copy and the installation identifier that were already kept there. Nothing new leaves your device.

    From its privacy statement, version 17.

    Beethoven for VS Code

    Its statement is at version 7 (2026-10-04) and keeps no list of changes.

    From its privacy statement, version 7.