fix: harden workspace trust and land session and terminal behavior

.agents/skills/review-pr/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: review-pr
+description: Use when reviewing a pull request in the pythinker-code repository — evaluate the change against the template structure.
+disable-model-invocation: true
+---
+
+# Review PR
+
+Review a pull request by evaluating the description against the template and the actual diff, then write a structured review summary in English.
+
+## Workflow
+
+1. Fetch the PR description and metadata:
+
+   ```bash
+   gh pr view <number> --json title,body,url,files,additions,deletions,baseRefName,headRefName
+   ```
+
+2. Read the full diff:
+
+   ```bash
+   gh pr diff <number>
+   ```
+
+3. Read enough surrounding code to verify the claims in the PR description.
+
+4. Evaluate each section against the criteria below.
+
+5. Write the review summary in English.
+
+## Review Criteria
+
+### Requirement or Bug
+
+- Is the linked issue valid and relevant?
+- If no issue, is the requirement clearly stated in one or two sentences?
+
+### Bug Reproduction Steps
+
+- For bug PRs: are the steps clear and reproducible?
+- Can you follow the steps to confirm the bug exists on the base branch?
+
+### Root Cause
+
+- For bug PRs: is the root cause convincingly explained?
+- Does the stated root cause match what you see in the diff?
+- Is it clear whether this is a fundamental fix or a workaround?
+
+### Code Changes
+
+- Does the description match the actual diff?
+- Are visual outlines (diff blocks, call trees, file trees) accurate and helpful?
+- Is the approach sound? Are there simpler alternatives?
+- Are there edge cases the author missed?
+
+### Impact Scope
+
+- Are all affected modules identified? Cross-check with the diff file list.
+- Does test coverage match the claimed scope?
+- Are there untested paths that carry risk?
+
+### Checklist
+
+- Are all applicable items checked?
+- For items marked as "not needed", do you agree?
+
+## Output
+
+Write the review summary in English. For each section:
+
+- State whether it is adequately filled in.
+- Flag anything missing, inaccurate, or inconsistent with the diff.
+- If the PR is ready, say so. If changes are needed, list them as actionable items.

.agents/skills/write-pr/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: write-pr
+description: Use when creating a pull request in the pythinker-code repository — how to fill in each section of the PR template with concise, reviewer-friendly content.
+---
+
+# Write PR Description
+
+Create or update the pull request for the current branch with a description that helps the reviewer understand why the change exists and the shape of the implementation.
+
+## Workflow
+
+1. Read the PR template:
+
+   `Read(.github/pull_request_template.md)`
+
+2. Identify or create the pull request:
+   - Check the current branch for an existing PR: `gh pr view --json url,number,title,state 2>/dev/null`.
+   - If no PR exists, inspect `git status --short --branch` and the commits on the current branch.
+   - Commit remaining changes, push the branch with an upstream, and create the PR with `gh pr create`.
+   - Follow the repository's git safety protocol.
+
+3. Gather the context needed to explain the change:
+   - Read the linked issue and any relevant task artifacts.
+   - Read the complete diff (`git diff main...HEAD`) and enough surrounding code to understand behavior and ownership.
+   - Use `gh pr view` to collect PR metadata and changed files if the PR already exists.
+
+4. Write the PR description following the template sections:
+   - **Requirement or Bug** — one sentence or `Resolve #<number>`. Nothing more.
+   - **Bug Reproduction Steps** — bug PRs only; `N/A` for features. Write `See linked issue` when steps are already there.
+   - **Root Cause** — bug PRs only; `N/A` for features. State the cause and whether this is a fundamental fix or a workaround.
+   - **Code Changes** — use visual outline views (see below) instead of prose whenever they explain the change better.
+   - **Impact Scope** — list affected modules and test coverage.
+   - **Checklist** — check every box that applies.
+
+5. Publish the description:
+   - Save to a temp file, then `gh pr edit <number> --body-file <path>` or `gh pr create --body-file <path>`.
+   - Confirm the update succeeded.
+
+## Visual Outline for Code Changes
+
+Prefer structural views over prose. Use the smallest combination that explains the implementation. Omit categories that did not change.
+
+Show logic or algorithm changes as pseudocode diff:
+
+```diff
+ on(save)
+-  write content
++  if content is unchanged
++    return cached result
++  write new content
++  invalidate cache
+```
+
+Show runtime control flow as a call tree diff:
+
+```diff
+ submitForm
+   createSession
+     persistPrompt
++    expandSkillMention
+     launchAgent
+-  navigateToSession
++  navigateToSession
++    subscribeToEvents
+```
+
+Show file responsibility changes as a shallow file tree diff:
+
+```diff
+ src/
+ ├── commands/
++│   └── show-me.ts       # expands the slash command
+ ├── sessions/
+-└── transport.ts
++└── transport/
++    ├── client.ts
++    └── stream.ts
+```
+
+Show component or UI structure changes as a tree diff:
+
+```diff
+ <SessionPage>
+   useSessionEvents()
+   <SessionToolbar>
++    <RunSkillButton />
+   <SessionTimeline>
++    <SkillResultCard />
+```
+
+Show component interaction, control flow, or data flow with Mermaid (especially useful for explaining bug mechanics):
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant UI
+    participant Daemon
+    User->>UI: choose command
+    UI->>Daemon: send expanded prompt
+    Daemon-->>UI: stream result
+```
+
+Show key data structure or type changes in a language-specific block:
+
+```ts
+interface SessionEvents {
+  onTurnStart(cb: (turn: Turn) => void): void;
+  onTurnEnd(cb: (turn: Turn) => void): void;
+}
+```
+
+Rules for visual outlines:
+- Use `diff` blocks when the point is what changes and the surrounding shape already exists.
+- Show the complete target shape in a language-specific or `text` block when most of it is new or diff notation would obscure ownership or order.
+- Tell the story in the order that makes it easiest to understand — files first, or data structures first, whichever fits.
+- Write as one human talking to another: simple, coherent, concise language.

.changeset/auto-session-title-config.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+Add `auto_session_title` so automatic session titles can be turned off.

.changeset/browser-extension-skill.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+The browser extension skill resends a failed command as a file and can move the local daemon off a busy port.

.changeset/fork-keeps-title-kind.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+A forked session keeps the source title kind when you do not set a new title.

.changeset/large-transcript-cache.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+Fix a crash when opening a session with a very large transcript.

.changeset/mcp-offline-access.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+MCP sign-in requests offline access when the authorization server advertises it.

.changeset/repeat-breaker-switch.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+Set `PYTHINKER_CODE_REPEAT_BREAKER=0` to turn off the repeated-tool-call stop.

.changeset/transcript-fold-and-jump.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+Click a transcript fold to open or close that block, and jump to the bottom when the transcript is scrolled up.

.changeset/tui-mode-setting.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+Choose a regular or fullscreen terminal layout with `tui_mode`.

.changeset/workspace-trust-and-symlink-guards.md

@@ -0,0 +1,5 @@
+---
+"@pymodel/pythinker-code": patch
+---
+
+File tools and git calls no longer follow a symlink out of the workspace, and project-local config waits for workspace trust.

.github/pull_request_template.md

@@ -5,24 +5,34 @@ External PRs are accepted for approved bug fixes only: link an issue that a main
 See https://github.com/PyModel/pythinker-code/blob/main/CONTRIBUTING.md for more.
 -->
 
-## Related Issue
+## Requirement or Bug
 
-<!-- Link the issue this change came from. External PRs must link an issue approved by a maintainer (an `/approve` comment) — PRs without one may be closed. -->
+<!-- If there's an issue, write Resolve #(issue_number).
+     If it's a requirement, describe it briefly in plain language (under 100 characters). -->
 
-Resolve #(issue_number)
+## Bug Reproduction Steps
 
-## Problem
+<!-- Required for bug PRs only; write N/A for feature PRs.
+     Prefer writing in the issue and linking here; if no issue exists, write directly. -->
 
-<!-- What user need or limitation does this address? If the linked issue already covers this, write "See linked issue". -->
+## Root Cause
 
-## What changed
+<!-- Required for bug PRs only. Explain the root cause.
+     State whether this is a fundamental fix or a workaround. -->
 
-<!-- What did you implement, and why does this approach fit Pythinker Code? -->
+## Code Changes
+
+<!-- Describe the code changes in plain, easy-to-understand language for the reviewer. -->
+
+## Impact Scope
+
+<!-- Describe which modules / functionality paths are affected;
+     what test coverage exists. -->
 
 ## Checklist
 
 - [ ] I have read the [CONTRIBUTING](https://github.com/PyModel/pythinker-code/blob/main/CONTRIBUTING.md) document.
-- [ ] I have linked a related issue (external PRs: the issue must have a maintainer's `/approve`).
+- [ ] I have linked a related issue (external PRs: issue must have a maintainer's `/approve`).
 - [ ] I have added tests that prove my feature works.
 - [ ] Ran `gen-changesets` skill, or this PR needs no changeset.
 - [ ] Ran `gen-docs` skill, or this PR needs no doc update.

AGENTS.md

@@ -115,7 +115,7 @@ Gate behind flags. Env: `PYTHINKER_CODE_EXPERIMENTAL_<NAME>` toggles one; `PYTHI
 - Prefer `rg` / `rg --files` for code reading.
 - Follow existing boundaries and local patterns.
 - Replace internal identifiers with neutral placeholders in public text/test data (e.g. `example.com`, `example.test`, `YOUR_API_KEY`). Before opening a PR, ask a read-only agent to audit the diff for context-specific internal identifiers.
-- PR titles: Conventional Commit style (e.g. `chore: remove legacy format commands`).
+- When creating a PR, use the `write-pr` skill (`.agents/skills/write-pr/SKILL.md`) to write the PR description. PR titles: Conventional Commit style (e.g. `chore: remove legacy format commands`).
 - Fill in `.github/pull_request_template.md` — link the issue, describe changes. No placeholder text or vague AI-generated PR summaries; the human author must understand the change well enough to explain the code, edge cases, and why the approach fits.
 - Run `gen-changesets` skill before submitting PRs. Changesets must strictly follow its rules: one short user-facing sentence stating only what changed; skip any change users cannot perceive. Never decide `major` on your own — stop, explain, and get explicit user confirmation first; default to `minor`, fall back to `patch`.
 - Changeset text is shipped text: the desktop release body is generated from `apps/desktop/CHANGELOG.md`, and the in-app updater shows it to users verbatim. A release body must state what changed for users — never a build stamp, a commit hash, or placeholder text. `desktop-release.yml` fails a stable release whose version has no changelog entry.

apps/pythinker-code/dist-web/.web-bundle-manifest.json

@@ -1,4 +1,4 @@
 {
-  "sourceHash": "e55e811106536d4ba7c56e5aa5d31c6d852cd0d560ec69e371349706de04ab06",
+  "sourceHash": "04602432b100c73fa465235500caccbe13e6af08198ab1c90198cdc5bd19fd1c",
   "sourceFileCount": 496
 }