What happened?
When PawWork opens the PawWork repository workspace, the embedded TypeScript language service can consume a full CPU core and several GB of memory. In the local observation on April 25, 2026, the heavy process was not a normal app service, lint task, or Biome process. It was typescript-language-server launched by PawWork, with child tsserver.js using about 97 percent CPU and around 3.4 GB RSS at peak. After the CPU dropped, the same tsserver.js process still kept about 2.6 GB RSS resident.
The process chain was PawWork to typescript-language-server to tsserver.js. The TypeScript server cwd was /Users/yuhan/workspace/dev/pawwork, and the command resolved workspace TypeScript from node_modules/.bun/typescript@5.8.2/node_modules/typescript/lib/tsserver.js. File evidence showed the server had opened hundreds of files from packages/opencode, packages/app, packages/ui, and node_modules/.bun.
Steps to reproduce
- Open PawWork v0.2.11.
- Open a large TypeScript monorepo workspace, using PawWork itself as the observed example.
- Read or inspect TypeScript source files so PawWork warms LSP state.
- Check Activity Monitor or run
ps for typescript-language-server and tsserver.js.
What did you expect to happen?
Opening or reading files in a large workspace should not start a TypeScript language service that analyzes the whole monorepo by default and holds multiple GB of memory. If LSP is available, it should stay bounded to the relevant package, be explicitly opt in for expensive analysis, or have a user visible way to disable TypeScript LSP for the project.
PawWork version
v0.2.11
OS version
macOS 26.3.1, build 25D771280a
Can you reproduce it again?
Only once so far, but the process state was persistent and directly observable.
Screenshots, recordings, or extra context
Observed process evidence: PID 39681 was node .../typescript-language-server --stdio, parented by PawWork. PID 39683 was node .../typescript/lib/tsserver.js, parented by PID 39681. At peak it used about 97 percent CPU and about 3.4 GB RSS. Later it idled at 0 percent CPU while still retaining about 2.6 GB RSS.
Initial root cause evidence: packages/opencode/src/lsp/server.ts enables the builtin TypeScript LSP and chooses the nearest package lock as the root. In this repository that resolves to the repo root because bun.lock is at the root. packages/opencode/src/tool/read.ts warms LSP after reading ordinary text files. The root tsconfig.json has no include or files, so TypeScript can treat the repository as a large inferred project. This points to TypeScript LSP project scoping and automatic warming, not Biome or lint, as the layer to fix.
Possible follow up directions: make the root tsconfig.json a solution config with files: [] and package references, avoid warming LSP from ordinary reads unless the user or workflow needs language intelligence, or expose a project config such as lsp.typescript.disabled as a documented performance escape hatch.
What happened?
When PawWork opens the PawWork repository workspace, the embedded TypeScript language service can consume a full CPU core and several GB of memory. In the local observation on April 25, 2026, the heavy process was not a normal app service, lint task, or Biome process. It was
typescript-language-serverlaunched by PawWork, with childtsserver.jsusing about 97 percent CPU and around 3.4 GB RSS at peak. After the CPU dropped, the sametsserver.jsprocess still kept about 2.6 GB RSS resident.The process chain was
PawWorktotypescript-language-servertotsserver.js. The TypeScript server cwd was/Users/yuhan/workspace/dev/pawwork, and the command resolved workspace TypeScript fromnode_modules/.bun/typescript@5.8.2/node_modules/typescript/lib/tsserver.js. File evidence showed the server had opened hundreds of files frompackages/opencode,packages/app,packages/ui, andnode_modules/.bun.Steps to reproduce
psfortypescript-language-serverandtsserver.js.What did you expect to happen?
Opening or reading files in a large workspace should not start a TypeScript language service that analyzes the whole monorepo by default and holds multiple GB of memory. If LSP is available, it should stay bounded to the relevant package, be explicitly opt in for expensive analysis, or have a user visible way to disable TypeScript LSP for the project.
PawWork version
v0.2.11
OS version
macOS 26.3.1, build 25D771280a
Can you reproduce it again?
Only once so far, but the process state was persistent and directly observable.
Screenshots, recordings, or extra context
Observed process evidence: PID 39681 was
node .../typescript-language-server --stdio, parented by PawWork. PID 39683 wasnode .../typescript/lib/tsserver.js, parented by PID 39681. At peak it used about 97 percent CPU and about 3.4 GB RSS. Later it idled at 0 percent CPU while still retaining about 2.6 GB RSS.Initial root cause evidence:
packages/opencode/src/lsp/server.tsenables the builtin TypeScript LSP and chooses the nearest package lock as the root. In this repository that resolves to the repo root becausebun.lockis at the root.packages/opencode/src/tool/read.tswarms LSP after reading ordinary text files. The roottsconfig.jsonhas noincludeorfiles, so TypeScript can treat the repository as a large inferred project. This points to TypeScript LSP project scoping and automatic warming, not Biome or lint, as the layer to fix.Possible follow up directions: make the root
tsconfig.jsona solution config withfiles: []and package references, avoid warming LSP from ordinary reads unless the user or workflow needs language intelligence, or expose a project config such aslsp.typescript.disabledas a documented performance escape hatch.