feat(vscode): pair with pairing URL by omegent-app[bot] · Pull Request #351 · patroza/t3code

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:27:15Z

Ports #237 by
@bulgadev onto fork/dev.

The original targets the now-frozen fork/vscode overlay branch and lives in a fork this repository
cannot push to, so it could not be rebased in place.

Attribution

The commit is authored by bulgadev <me@bulgaaw.com>, not merely credited — git cherry-pick
preserved it and the amend kept it. Co-authored-by is added on top as insurance: fork/dev is
squash-only, and a squash can rewrite the author while trailers survive in the body either way.

Please merge this rather than #237, and close#237 pointing here.

Content

Adds a T3 Code: Pair with Server… command accepting a full pairing URL
(http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via
the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up
as the bearer tier. Removes the need to hand-exchange tokens with curl before using Set Server
Bearer Token.

Unchanged from the original — 5 files, cherry-picked cleanly onto fork/dev with no conflicts.

Validation

apps/vscode suite: 13 files, 44 tests pass.
Full recursive typecheck clean across all 17 packages.

Note on the other external PR

#238 is not ported, because it is already fixed on
fork/dev by a different route and porting it would duplicate the behaviour:

ResolvedKeybindingsConfig already uses the generic ForwardCompatibleArray helper, whose decode
keeps only elements that decode and encodes unchanged — identical semantics to the bespoke
filterKnownResolvedKeybindingRules the PR introduces.
fork/dev's tests are strictly broader: unknown commands, unknown when-node types, and
malformed entries. fix(contracts): tolerate unknown keybinding commands on client decode #238 covers only the first.
One of fix(contracts): tolerate unknown keybinding commands on client decode #238's assertions would now fail: it asserts filePicker.toggle decodes away as
unknown, but that command has since shipped and is known.

Recommend closing #238 as already fixed, with credit to @bulgadev for reporting the class of bug.

Co-authored by @patroza, @bulgadev

opened by Patrick Roza in chat thread Discord · Discord · T3

Adds a "T3 Code: Pair with Server…" command that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint, and stores it in SecretStorage so ensureConnected picks it up as the bearer tier. Removes the need to hand-exchange tokens with curl before using the Set Server Bearer Token command. Co-Authored-By: Claude <noreply@anthropic.com> Ported to fork/dev from the external pull request #237, which was opened against the now-frozen fork/vscode overlay branch from a fork this repository cannot push to. Authorship is preserved on the commit; the trailer below keeps the credit attached through a squash merge, which is the only merge method fork/dev allows. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

Review of #351 raised two problems with the pairing flow. The token is issued by the server named in the pairing URL, but the flow then called ensureConnected(), which walks the desktop and configured candidates and offers the bearer to each in turn. Pairing with server B therefore disclosed B's token to server A, whichever A happened to be first. Bearer tokens are now pinned to the endpoint that issued them. bearerTokenAppliesTo() gates every use, and the paired endpoint becomes the first connection candidate so pairing actually connects where the user pointed it. Pinning alone would have left the extension connecting to A without the token, which is a quieter kind of wrong. Tokens with no recorded endpoint stay unpinned: they predate this change or were entered by hand through Set Server Bearer Token, where the user chose the destination. Set and Clear both maintain the endpoint alongside the token, so a hand-entered token cannot inherit a previous pairing's scope. The token was also written to SecretStorage before the connection was proven, so a failed pairing destroyed a working credential. Exchange, connect to the issuing endpoint and wait for the shell first; store only once that succeeds. Nothing is written on failure, so there is no previous value to restore. Co-authored-by: bulgadev <me@bulgaaw.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

bulgadevand others added 2 commits August 6, 2026 07:26

omegent-appBot merged commit 4a13d96 into fork/devAug 6, 2026
7 checks passed

This was referenced Aug 6, 2026
feat(vscode): pair with pairing URL #237
Closed
fix(contracts): tolerate unknown keybinding commands on client decode #238
Closed

Conversation

omegent-appBot commented Aug 6, 2026

Attribution

Content

Validation

Note on the other external PR

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Attribution

Content

Validation

Note on the other external PR

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Attribution

Content

Validation

Note on the other external PR

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Attribution

Content

Validation

Note on the other external PR

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Attribution

Content

Validation

Note on the other external PR

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant