feat: allow a turn to preserve the thread's current runtime mode
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 56/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- api, backend-api-design
Research direction
Start at the thread.turn.start payload handling and the thread.turn-start-requested reducer, comparing its runtimeMode behavior with the conditional modelSelection handling. Check the thread.runtime-mode.set command to preserve deliberate mode changes. Done means a turn can preserve the thread's existing mode without overwriting it, while explicit mode changes still work.
Written by the indexing model from the issue text.
Description
What I'm building
An external orchestrator that drives t3 threads over the WebSocket RPC. It starts turns on
threads that a human also uses interactively.
Problem
runtimeMode is required on every thread.turn.start payload — not optional, not
create-only — and the thread.turn-start-requested reducer writes it onto the thread
unconditionally. That is asymmetric with modelSelection, which the same reducer writes
conditionally.
The t3 client itself never notices, because it resolves
explicitOverride ?? thread.runtimeMode ?? project.default on every turn — i.e. it echoes
the thread's current mode unless the user deliberately changed it, and there is a separate
thread.runtime-mode.set command for that case.
For any other client this means: to send a turn at all, you must already know the thread's
current mode. Any constant you pick silently re-permissions a live session — sending
full-access to a thread the operator has put in approval-required widens permissions
without the operator doing anything, and the change persists on the thread afterwards.
Observed in 0.0.42, reading the installed build.
Ask
Let a turn say "keep what the thread has": accept thread.turn.start without runtimeMode,
or accept an explicit "preserve" sentinel, and in that case leave the stored thread mode
untouched — the conditional treatment modelSelection already gets. thread.runtime-mode.set
stays the way a client changes the mode deliberately.
- Dominant language
- TypeScript
- Stars
- 23.3k
- Forks
- 6k
- Avg merge
- 10h 57m
- Merged PRs (30d)
- 365
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pingdotgg/t3code
-
bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
All issues in pingdotgg/t3code
Similar issues
-
Browser Waiting for: Product Owner
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
getsentry/sentry-javascript#24577 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
agilepathway/label-checker#640 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
agentic-workflows
Difficulty 1/5 Under an hour Newbie friendliness 85/100
githubnext/rig#534 ·
-
automation missing-model model-sync provider:pioneer
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
anomalyco/models.dev#7701 ·