@researai/deepscientist 1.5.14 → 1.5.16

package/src/skills/rebuttal/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: rebuttal
 description: Use when a quest already has a paper, draft, or review package and the task is to map reviewer feedback into experiments, manuscript deltas, and a durable rebuttal / revision response.
+skill_role: companion
 ---
 
 # Rebuttal
@@ -18,6 +19,7 @@ The task is “respond to concrete reviewer pressure with the smallest honest se
 - Message templates are references only. Adapt to the actual context and vary wording so updates feel natural and non-robotic.
 - If a threaded user reply arrives, interpret it relative to the latest rebuttal progress update before assuming the task changed completely.
 - When the rebuttal plan, the main supplementary-evidence package, or the final response bundle becomes durable, send one richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what reviewer concerns are now addressed, what still remains open, and what happens next.
+- Hard execution rule: if this stage needs terminal work such as manuscript builds, scripted checks, Git inspection, or reviewer-linked experiment launches, every such command must go through `bash_exec`.
 
 ## Purpose
 
@@ -423,7 +425,7 @@ Open additional skills only when the rebuttal workflow requires them:
 
 Use these tools deliberately:
 
-- `artifact.record(kind='decision', ...)`
+- `artifact.record(payload={'kind': 'decision', ...})`
   - route choice, claim downgrade, literature-audit launch, baseline-recovery launch, supplementary-experiment launch, rebuttal completion recommendation
 - `artifact.create_analysis_campaign(...)`
   - multi-slice reviewer-driven supplementary work

package/src/skills/review/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: review
 description: Use when a draft, paper, or paper-like report is substantial enough for an independent skeptical audit before finalization, rebuttal, or revision routing.
+skill_role: companion
 ---
 
 # Review
@@ -19,6 +20,7 @@ It is also not the same as `rebuttal`.
 - Follow the shared interaction contract injected by the system prompt.
 - For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
 - When the review report, revision plan, or follow-up experiment TODO list becomes durable, send a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what the main risks are, what should be fixed next, and whether the next route is writing, experiment, or claim downgrade.
+- Hard execution rule: if this stage needs terminal work such as document builds, scripted checks, Git inspection, or file inspection, every such command must go through `bash_exec`.
 
 ## Purpose
 
@@ -356,7 +358,7 @@ Open additional skills only when the review workflow requires them:
 
 Use these tools deliberately:
 
-- `artifact.record(kind='decision', ...)`
+- `artifact.record(payload={'kind': 'decision', ...})`
   - review conclusion, claim downgrade recommendation, route choice, stop/go recommendation
 - `artifact.create_analysis_campaign(...)`
   - when the experiment TODO list should become concrete follow-up slices

package/src/skills/scout/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: scout
 description: Use when a quest needs problem framing, literature scouting, dataset or metric clarification, or baseline discovery before deeper work.
+skill_role: stage
 ---
 
 # Scout
@@ -15,6 +16,13 @@ Use this skill when the quest does not yet have a stable research frame.
 - If a threaded user reply arrives, interpret it relative to the latest scout progress update before assuming the task changed completely.
 - When scouting actually resolves the framing ambiguity, locks the evaluation contract, or makes the next anchor obvious, send one richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what is now clear, why it matters, and which stage should come next.
 
+## Tool discipline
+
+- **Do not use native `shell_command` / `command_execution` in this skill.**
+- **Any shell, CLI, Python, bash, node, git, npm, uv, or repo-inspection execution must go through `bash_exec(...)`.**
+- **For git inspection inside the current quest repository or worktree, prefer `artifact.git(...)` before raw shell git commands.**
+- **If scouting only needs durable quest context, prefer `artifact.read_quest_documents(...)`, `artifact.get_quest_state(...)`, and `memory.*` instead of shelling out.**
+
 ## Stage purpose
 
 The scout stage exists to answer the smallest set of framing questions required to make the rest of the quest efficient:

package/src/skills/write/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: write
 description: Use when a quest has enough evidence to draft or refine a paper, report, or research summary without inventing missing support.
+skill_role: stage
 ---
 
 # Write
@@ -21,6 +22,7 @@ This skill intentionally absorbs the strongest old DeepScientist writing discipl
 
 - Follow the shared interaction contract injected by the system prompt.
 - For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
+- Hard execution rule: every terminal command in this stage must go through `bash_exec`; do not use any other terminal path for LaTeX builds, figure generation, scripted export, Git, Python, package-manager, or file-inspection commands.
 - Prefer `bash_exec` for durable document-build commands such as LaTeX compilation, figure regeneration, and scripted export steps so logs remain quest-local and reviewable.
 - Keep ordinary subtask completions concise. When a paper/draft milestone is actually completed, upgrade to a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` report instead of another short progress update.
 - That richer writing-stage milestone report should normally cover: which draft, section, or outline milestone finished, what is now supportable, what is still missing, and the exact recommended next revision or route decision.
@@ -63,6 +65,7 @@ It exists to test whether the current evidence can support a stable narrative.
 Writing should happen on a dedicated `paper/*` branch/worktree derived from the source main-experiment `run/*` branch.
 Treat that paper branch as the writing surface, and treat the parent run branch as the evidence source that writing must faithfully reflect.
 Do not run new main experiments from the paper branch; if writing exposes a missing evidence requirement, route back through `decision`, `activate_branch`, `experiment`, or `analysis-campaign`.
+Once an outline is selected, treat that branch/worktree as an active paper line with its own contract, not just as a late draft folder.
 
 If the evidence is incomplete, contradictory, or too weak, the correct output is:
 
@@ -85,6 +88,17 @@ The approved outline should be a real structured object, typically containing:
   - `experimental_designs`
   - `contributions`
 
+Treat the approved outline as the paper contract, not just a narrative sketch.
+It should decide:
+
+- which sections exist
+- which experiments or analysis items each section depends on
+- which evidence belongs in main text, appendix, or reference-only support
+
+If the selected outline is missing those links, repair the outline and matrix before further drafting.
+Prefer an author-facing outline folder under `paper/outline/` with section-level files, and treat `paper/selected_outline.json` as the compiled compatibility view of that contract.
+`paper/evidence_ledger.json` remains the runtime truth of what evidence actually exists and where it maps.
+
 ## Writing mental guardrails
 
 - Writing starts when the claim and evidence structure are stable enough, not when prose feels easy.
@@ -120,8 +134,27 @@ Before writing seriously, confirm:
 - the claims you intend to write are backed by durable artifacts
 - the code/diff path is available for method fidelity checks
 - the evaluation contract is explicit
+- the active paper line is known
+- the selected outline is present and reflects the current evidence line
+- `paper/outline/manifest.json` and any relevant section files are present when the outline folder flow is enabled
+- `paper/evidence_ledger.json` or `paper/evidence_ledger.md` reflects the current mapped paper evidence set
+- `paper/paper_experiment_matrix.md` reflects the current paper-facing experiment and analysis frontier when that planning surface is in use
+- completed relevant analysis results under `experiments/analysis-results/` are mapped into the selected outline or matrix rather than floating only as standalone reports
 
 If major claims lack evidence, surface the gap first.
+If the selected outline, outline folder, evidence ledger, or matrix feels underspecified, read `references/outline-evidence-contract-example.md` before drafting further.
+For paper-facing work, use this hard order instead of drifting between surfaces:
+
+1. refresh the active outline folder section files first when they exist
+2. sync the compiled `paper/selected_outline.json`
+3. confirm `paper/evidence_ledger.json` reflects the same mapped evidence set
+4. only then draft, revise, review, or bundle prose
+
+Do not draft first and promise to repair the paper contract later.
+If the current blocker set is not obvious from files, call `artifact.get_paper_contract_health(detail='full')` before deciding whether to keep writing or to return to contract repair / supplementary work.
+If the active quest status, current workspace, recent durable runs, or pending interaction state is unclear after a restart, call `artifact.get_quest_state(detail='summary')` first.
+If the exact current brief/plan/status/summary wording matters for the current drafting decision, call `artifact.read_quest_documents(...)` instead of relying on prompt-injected excerpts.
+If you need earlier user/assistant continuity to interpret the current writing request, call `artifact.get_conversation_context(...)` before changing the route.
 
 ## Truth sources
 
@@ -139,12 +172,19 @@ Use these as the canonical evidence base:
 
 Do not rely on memory alone for numbers.
 Always prefer direct artifact paths for claims.
+Do not keep drafting from remembered storyline summaries if the active paper line already has a stricter durable contract in its outline folder, selected outline, evidence ledger, experiment matrix, or paper-facing analysis mirrors.
 
 ## Required durable outputs
 
 The write stage should usually produce most of the following:
 
-- `paper/outline.md` or equivalent outline
+- `paper/outline/manifest.json`
+- `paper/outline/sections/<section_id>/section.md`
+- `paper/outline/sections/<section_id>/result_table.json`
+- `paper/outline/sections/<section_id>/experiment_setup.md`
+- `paper/outline/sections/<section_id>/findings.md`
+- `paper/outline/sections/<section_id>/impact.md`
+- `paper/outline.md` or equivalent outline view
 - `paper/selected_outline.json`
 - `paper/paper_experiment_matrix.md`
 - `paper/paper_experiment_matrix.json`
@@ -172,7 +212,8 @@ The write stage should usually produce most of the following:
 
 The exact paths may vary, but the structure and meaning should remain clear.
 
-Treat the approved outline as the authoritative blueprint for the draft.
+Treat the author-facing outline folder and compiled selected outline together as the authoritative blueprint for the draft.
+If both exist, update the outline folder first and then keep `paper/selected_outline.json` synchronized as the compiled compatibility output.
 Treat `paper/draft.md` or the equivalent working note as the running evidence ledger where useful findings, citation notes, and writing decisions are accumulated as work proceeds.
 After every significant search, plot, paragraph, revision pass, or claim downgrade, update the working note and writing plan immediately so important writing state is not trapped in transient chat output.
 For any substantial paper-writing line, keep `paper/writing_plan.md` or an equivalent durable plan detailed enough that another agent could resume from it without reconstructing the full logic from chat alone.
@@ -212,8 +253,10 @@ For any paper-like writing line that has more than a trivial single-result story
 - `paper/paper_experiment_matrix.json`
 
 Use `references/paper-experiment-matrix-template.md` when helpful.
+Use `references/outline-evidence-contract-example.md` when the paper line needs a concrete example of section binding, `required_items`, and `result_table` updates.
 
-The paper experiment matrix is the durable experiment-control surface for the paper line.
+The paper experiment matrix is the planning and reporting surface for the paper line.
+It is not the master truth when it disagrees with the selected outline contract or `paper/evidence_ledger.json`.
 It exists to prevent two common failures:
 
 - an outline that overweights post-hoc analysis and under-specifies paper-typical experiments
@@ -231,6 +274,18 @@ It should cover the full paper-facing experiment program beyond the already-fini
 - failure-boundary or limitation-surface analyses
 - case study or trace walkthrough rows as optional supporting material rather than mandatory core evidence
 
+The matrix should also act as the ingestion gate for completed follow-up analysis:
+
+- if a completed analysis campaign or slice is relevant to a paper claim, it must appear in the matrix as `main_required`, `appendix`, `reference_only`, or be excluded with a written reason
+- do not allow completed analysis results to remain paper-invisible
+
+The outline should be revised in lockstep with that matrix:
+
+- before analysis begins, seed the section structure and expected evidence items
+- after each completed slice, update the matching section's `result_table`
+- if the outline folder exists, update the section's `experiment_setup.md`, `findings.md`, and `impact.md` instead of leaving those changes only in prose notes
+- if a result weakens the claim, downgrade the section contract before polishing prose
+
 Case study is usually optional.
 Do not let it displace stronger quantitative evidence.
 Efficiency or cost experiments are not mandatory in every paper, but they should be added whenever:
@@ -342,6 +397,15 @@ After every meaningful experiment outcome, even a null result or exclusion:
 Do not decide the next supplementary experiment from memory alone when the matrix exists.
 The matrix should be the authoritative experiment-routing surface for the paper line, and the selected outline's `experimental_designs` should stay consistent with that matrix rather than drifting away from it.
 
+Before drafting any section, verify all of the following:
+
+- the section exists in the selected outline
+- the section's required experiment or analysis items are present in `paper/paper_experiment_matrix.*`
+- every main-text-required item for that section is already completed or honestly blocked
+- no completed relevant analysis slice remains unmapped
+
+If any of those checks fails, stop drafting and repair the paper contract first.
+
 ## Venue template selection
 
 For paper-like writing, use a real venue template rather than improvising a blank LaTeX tree.
@@ -385,14 +449,18 @@ For paper-like deliverables, the safest default order is:
 2. activate or create the dedicated `paper/*` branch/worktree derived from the source run branch before durable outline selection or drafting
 3. choose the venue template from `templates/`, copy it into `paper/latex/`, and default general ML work to `templates/iclr2026/` unless a stronger venue target exists
 4. if the line benefits from an explicit outline contract, record one or more outline candidates with `artifact.submit_paper_outline(mode='candidate', ...)`
-5. if one outline should become the durable paper contract, select or revise it with `artifact.submit_paper_outline(mode='select'|'revise', ...)`
-6. create or refresh `paper/paper_experiment_matrix.md` and `paper/paper_experiment_matrix.json` before stabilizing the experiments section
-7. if the selected outline or matrix still exposes evidence gaps, launch an outline-bound and matrix-bound `artifact.create_analysis_campaign(...)` before drafting the experiments section as if it were settled
-8. plan and generate decisive figures or tables
-9. draft sections directly from the evidence and the current working outline; do not force extra outline rounds when direct drafting is clearer and safer
-10. run harsh review and revision cycles
-11. proof, package, submit `artifact.submit_paper_bundle(...)` when the bundle is ready, and then pass to `finalize`
-12. if the final paper PDF exists and QQ milestone media is enabled in config, the bundle-ready milestone may attach that PDF once
+5. if one outline should become the durable paper contract, select or revise it with `artifact.submit_paper_outline(mode='select'|'revise', ...)`; that selection should be treated as opening or refreshing the active paper line
+6. if the outline folder flow is enabled, create or refresh `paper/outline/manifest.json` and the relevant section files before stabilizing the experiments section
+7. create or refresh `paper/paper_experiment_matrix.md` and `paper/paper_experiment_matrix.json` before stabilizing the experiments section
+8. if the selected outline or matrix still exposes evidence gaps, launch an outline-bound and matrix-bound `artifact.create_analysis_campaign(...)` before drafting the experiments section as if it were settled
+9. after every completed follow-up slice, reopen the selected outline and confirm the corresponding `result_table` row now reflects the real result rather than a placeholder
+10. if the outline folder exists, immediately sync the affected section files so experiment setup, findings, and impact stay current on the paper line
+11. after that sync, confirm `paper/evidence_ledger.json` and the paper line summary still agree before continuing prose work
+12. plan and generate decisive figures or tables
+13. draft sections directly from the evidence and the current working outline; do not force extra outline rounds when direct drafting is clearer and safer
+14. run harsh review and revision cycles
+15. proof, package, submit `artifact.submit_paper_bundle(...)` when the bundle is ready, and then pass to `finalize`
+16. if the final paper PDF exists and QQ milestone media is enabled in config, the bundle-ready milestone may attach that PDF once
 
 Before real drafting, force one explicit planning pass that stabilizes at least:
 
@@ -1202,6 +1270,7 @@ Preferred artifact choices:
   - draft readiness when a user-facing checkpoint helps
 - use `approval` when the user explicitly confirms a submission-critical choice
 - use `artifact.submit_paper_outline(mode='candidate'|'select'|'revise', ...)` for the real outline lifecycle instead of leaving outline choice only in prose
+- when `mode='select'`, treat the selected outline as the activation point of the active paper line and keep its folder/json contract synchronized
 - use `artifact.submit_paper_bundle(...)` before leaving the writing stage when the draft, plan, references, and packaging evidence are durable enough
 - continue writing on the dedicated `paper/*` branch/worktree after analysis slices finish; treat the parent run or idea branch as the evidence source, not the drafting surface
 
@@ -1239,7 +1308,7 @@ Use these references when the deliverable is paper-like and you need a denser op
 
 Exit the write stage only when one of the following is durably true:
 
-- the current draft is evidence-complete enough for `finalize`, including a selected outline and a durable paper bundle manifest when the deliverable is paper-like
+- the current draft is evidence-complete enough for `finalize`, including an active paper line, a selected outline, synchronized outline contract files, and a durable paper bundle manifest when the deliverable is paper-like
 - a clear evidence gap has been recorded and the quest is routed backward
 - a packaging or proofing blocker has been recorded and the next action is explicit
 

package/src/skills/write/references/outline-evidence-contract-example.md

@@ -0,0 +1,107 @@
+# Outline-Centered Paper Contract Example
+
+Use this reference when the paper line needs a concrete example of:
+
+- what a selected outline should look like before follow-up analysis
+- how completed evidence should be written back into the outline
+- what should block further drafting
+
+## Minimal selected outline shape
+
+```json
+{
+  "outline_id": "outline-002",
+  "title": "Truth-Preserving Collaboration under Mixed Signals",
+  "story": "Motivation -> bottleneck -> remedy -> evidence -> boundary",
+  "detailed_outline": {
+    "research_questions": [
+      "RQ1: Does the method improve the main benchmark under the accepted protocol?",
+      "RQ2: Which component actually causes the gain?",
+      "RQ3: Where does the method fail or regress?"
+    ],
+    "experimental_designs": [
+      "Main benchmark comparison",
+      "Component ablation",
+      "Boundary / failure analysis"
+    ],
+    "contributions": [
+      "A new route for source-aware collaboration",
+      "A controlled decomposition of the gain",
+      "A clearer limitation boundary"
+    ]
+  },
+  "evidence_contract": {
+    "main_text_items_must_be_ready": true,
+    "appendix_items_may_be_ready_or_reference_only": true,
+    "record_results_back_into_outline": true,
+    "result_table_required": true
+  },
+  "sections": [
+    {
+      "section_id": "results-main",
+      "title": "Main Results",
+      "paper_role": "main_text",
+      "claims": ["C1"],
+      "required_items": ["run-main-001"],
+      "optional_items": [],
+      "status": "pending",
+      "result_table": []
+    },
+    {
+      "section_id": "analysis-mechanism",
+      "title": "Mechanism Analysis",
+      "paper_role": "main_text",
+      "claims": ["C2"],
+      "required_items": ["AN-ABL-001"],
+      "optional_items": [],
+      "status": "pending",
+      "result_table": []
+    },
+    {
+      "section_id": "analysis-boundary",
+      "title": "Boundary and Failure Analysis",
+      "paper_role": "appendix",
+      "claims": ["C3"],
+      "required_items": [],
+      "optional_items": ["AN-BND-001"],
+      "status": "planned",
+      "result_table": []
+    }
+  ]
+}
+```
+
+## After one completed analysis slice
+
+Write the result back into the matching `section.result_table`.
+
+```json
+{
+  "item_id": "AN-ABL-001",
+  "title": "Remove corroboration module",
+  "kind": "analysis_slice",
+  "paper_role": "main_text",
+  "status": "completed",
+  "claim_links": ["C2"],
+  "metric_summary": "acc=0.811; delta=-0.046",
+  "result_summary": "Removing the corroboration module eliminates most of the measured gain.",
+  "source_paths": [
+    "experiments/analysis/analysis-1234/ablation/RESULT.md",
+    "experiments/analysis-results/analysis-1234/ablation.md"
+  ],
+  "updated_at": "2026-03-28T00:00:00Z"
+}
+```
+
+The matching section should then move from `pending` to:
+
+- `ready` if every required item is ready
+- `partial` if some required items are ready
+- `pending` if the row exists but the result is not ready
+
+## Drafting rules by case
+
+- If a section has missing required items, stop prose expansion and repair the evidence contract first.
+- If an analysis slice is completed but has no `section_id` or `item_id`, do not summarize it in the paper yet; map it first.
+- If a result is only useful as support, keep it in `appendix` or `reference_only` instead of inflating the main text.
+- If the result weakens the claim, record that downgrade in the outline before rewriting the section prose.

package/src/tui/dist/app/AppContainer.js

@@ -93,16 +93,18 @@ const buildQuestConfigItems = (questId, questRoot) => {
             documentId: 'path::quest.yaml',
         },
     ];
-    const codexPath = `${questRoot}/.codex/config.toml`;
-    if (fs.existsSync(codexPath)) {
+    const codexCandidates = [`${questRoot}/.ds/codex-home/config.toml`, `${questRoot}/.codex/config.toml`];
+    const codexPath = codexCandidates.find((candidate) => fs.existsSync(candidate));
+    if (codexPath) {
+        const relativeCodexPath = codexPath.replace(`${questRoot}/`, '');
         items.push({
-            id: `quest:${questId}:.codex/config.toml`,
+            id: `quest:${questId}:${relativeCodexPath}`,
             scope: 'quest',
-            name: '.codex/config.toml',
-            title: '.codex/config.toml',
+            name: relativeCodexPath,
+            title: relativeCodexPath,
             path: codexPath,
             writable: true,
-            documentId: 'path::.codex/config.toml',
+            documentId: `path::${relativeCodexPath}`,
         });
     }
     return items;
@@ -480,18 +482,21 @@ function openBrowser(url) {
     }
     spawn('xdg-open', [url], { detached: true, stdio: 'ignore' }).unref();
 }
-function buildProjectsUrl(baseUrl) {
+function buildProjectsUrl(baseUrl, authToken) {
     const target = new URL(baseUrl);
     if (target.hostname === '0.0.0.0') {
         target.hostname = '127.0.0.1';
     }
     target.pathname = '/projects';
     target.search = '';
+    if (authToken) {
+        target.searchParams.set('token', authToken);
+    }
     return target.toString();
 }
-function buildProjectUrl(baseUrl, questId) {
+function buildProjectUrl(baseUrl, questId, authToken) {
     if (!questId) {
-        return buildProjectsUrl(baseUrl);
+        return buildProjectsUrl(baseUrl, authToken);
     }
     const target = new URL(baseUrl);
     if (target.hostname === '0.0.0.0') {
@@ -499,9 +504,12 @@ function buildProjectUrl(baseUrl, questId) {
     }
     target.pathname = `/projects/${questId}`;
     target.search = '';
+    if (authToken) {
+        target.searchParams.set('token', authToken);
+    }
     return target.toString();
 }
-export const AppContainer = ({ baseUrl, initialQuestId = null, }) => {
+export const AppContainer = ({ baseUrl, initialQuestId = null, authToken = null, }) => {
     const { exit } = useApp();
     const [quests, setQuests] = useState([]);
     const [connectors, setConnectors] = useState([]);
@@ -1604,6 +1612,9 @@ export const AppContainer = ({ baseUrl, initialQuestId = null, }) => {
         setInput('');
         setStatusLine(nextStatus);
     }, []);
+    const openConfigBrowser = useCallback((nextStatus) => {
+        openConfigRoot(nextStatus);
+    }, [openConfigRoot]);
     const openConnectorBrowser = useCallback(async (targetConnector) => {
         try {
             const document = await loadConnectorsDocument();
@@ -2537,7 +2548,7 @@ export const AppContainer = ({ baseUrl, initialQuestId = null, }) => {
             return;
         }
         if (key.ctrl && value.toLowerCase() === 'o') {
-            openBrowser(buildProjectUrl(baseUrl, activeQuestId || browseQuestId));
+            openBrowser(buildProjectUrl(baseUrl, activeQuestId || browseQuestId, authToken));
             return;
         }
         if (key.ctrl && value.toLowerCase() === 'g') {

package/src/tui/dist/index.js

@@ -1,6 +1,7 @@
 import React from 'react';
 import { render } from 'ink';
 import { AppContainer } from './app/AppContainer.js';
+import { setDaemonAuthToken } from './lib/api.js';
 import { isAlternateBufferEnabled, isIncrementalRenderingEnabled } from './utils/terminal.js';
 const CLEAR_TO_END = '\x1b[0K';
 const BRACKETED_PASTE_ENABLE = '\x1b[?2004h';
@@ -31,6 +32,8 @@ function parseArg(name) {
 }
 const baseUrl = parseArg('--base-url') ?? 'http://0.0.0.0:20999';
 const questId = parseArg('--quest-id');
+const authToken = parseArg('--auth-token');
+setDaemonAuthToken(authToken);
 const useAlternateBuffer = isAlternateBufferEnabled();
 const useIncrementalRendering = isIncrementalRenderingEnabled();
 const setBracketedPasteMode = (enabled) => {
@@ -54,7 +57,7 @@ const closeBracketedPasteMode = () => {
 };
 setBracketedPasteMode(true);
 process.once('exit', closeBracketedPasteMode);
-const instance = render(React.createElement(AppContainer, { baseUrl: baseUrl, initialQuestId: questId }), {
+const instance = render(React.createElement(AppContainer, { baseUrl: baseUrl, initialQuestId: questId, authToken: authToken }), {
     stdout: withLineClearing(process.stdout),
     stderr: process.stderr,
     stdin: process.stdin,

package/src/tui/dist/lib/api.js

@@ -1,3 +1,29 @@
+let daemonAuthToken = null;
+function toHeaderRecord(headers) {
+    if (!headers)
+        return {};
+    if (headers instanceof Headers) {
+        return Object.fromEntries(headers.entries());
+    }
+    if (Array.isArray(headers)) {
+        return Object.fromEntries(headers);
+    }
+    return { ...headers };
+}
+function authHeaders(headers) {
+    const normalizedToken = typeof daemonAuthToken === 'string' ? daemonAuthToken.trim() : '';
+    if (!normalizedToken) {
+        return toHeaderRecord(headers);
+    }
+    return {
+        ...toHeaderRecord(headers),
+        Authorization: `Bearer ${normalizedToken}`,
+    };
+}
+export function setDaemonAuthToken(value) {
+    const normalized = typeof value === 'string' ? value.trim() : '';
+    daemonAuthToken = normalized || null;
+}
 async function parseResponse(response) {
     if (!response.ok) {
         throw new Error(await response.text());
@@ -6,10 +32,11 @@ async function parseResponse(response) {
 }
 export async function api(baseUrl, path, init) {
     const response = await fetch(`${baseUrl}${path}`, {
+        ...init,
         headers: {
             'Content-Type': 'application/json',
+            ...authHeaders(init?.headers),
         },
-        ...init,
     });
     return parseResponse(response);
 }
@@ -68,6 +95,7 @@ export const client = {
         const response = await fetch(client.eventsStreamUrl(baseUrl, questId, cursor), {
             headers: {
                 Accept: 'text/event-stream',
+                ...authHeaders(),
             },
             signal: callbacks.signal,
         });
@@ -128,7 +156,9 @@ export const client = {
             search.set('order', params.order);
         }
         const suffix = search.toString() ? `?${search.toString()}` : '';
-        const response = await fetch(`${baseUrl}/api/quests/${questId}/bash/sessions/${bashId}/logs${suffix}`);
+        const response = await fetch(`${baseUrl}/api/quests/${questId}/bash/sessions/${bashId}/logs${suffix}`, {
+            headers: authHeaders(),
+        });
         if (!response.ok) {
             throw new Error(await response.text());
         }
@@ -151,7 +181,7 @@ export const client = {
         }
         const response = await fetch(`${baseUrl}/api/quests/${questId}/bash/sessions/${bashId}/stream`, {
             method: 'GET',
-            headers,
+            headers: authHeaders(headers),
             signal: callbacks.signal,
         });
         if (!response.ok || !response.body) {

package/src/tui/package.json

@@ -1,6 +1,6 @@
 {
   "name": "deepscientist-tui",
-  "version": "1.5.14",
+  "version": "1.5.16",
   "private": true,
   "type": "module",
   "main": "dist/index.js",