If you’ve ever noticed your machine feeling sluggish hours after closing VS Code, you might have been hosting an uninvited guest. The Odoo Language Server — the background process that powers autocompletion, diagnostics, and navigation for Odoo module development — had a quiet habit of surviving its parent editor. Close VS Code, crash it, force-kill it, it didn’t matter: the language server would log “Channel disconnected. Exiting program” and then, contradicting its own promise, keep right on running. Version 1.6.2 finally puts a stake through that zombie and bundles two more quality-of-life fixes that make daily Odoo development a noticeably less abrasive experience.
The Zombie That Wouldn’t Die
The root cause was a classic Unix process management oversight. The language server relied on a parent-process check to detect when its host editor disappeared. On paper, the mechanism is sound: poll the parent PID, and if it’s gone, shut down gracefully. In practice, the check was failing with ECHILDon every single invocation — a “no child processes” error that the server silently swallowed. Because the detection never succeeded, the server never learned that VS Code had left. It just sat there, consuming memory and CPU cycles, invisible to anyone who wasn’t checking their process list.
The behavior was consistent across both Ubuntu and macOS, and it affected every installation running the official VS Code extension. Developers who habitually open and close multiple workspace windows throughout the day could accumulate a small fleet of orphaned language server instances without realizing it. The fix corrects the disconnect detection so the server now recognizes when its parent process is no longer alive and terminates cleanly. No more lingering processes, no more phantom resource drain.
Color Comes to the Terminal
The second improvement addresses something that’s been a persistent papercut for developers who rely on terminal output when debugging module issues. Until now, the Odoo Language Server dumped its logs in monochrome — every info message, warning, and error rendered in the same undifferentiated stream of white text. Scanning for a specific warning in a wall of identically colored output is the kind of friction that adds up to real lost time over weeks of development.
Version 1.6.2 introduces automatic ANSI color detection, built on the same color-handling approach that the Rust package manager Cargo uses internally. The server now probes the terminal at startup to determine whether it supports color escape sequences, and if it does, log output gets color-coded by severity. Informational messages appear in green, debug traces in purple, warnings in amber, and errors in red. For environments where automatic detection doesn’t produce the right result — piped output, CI runners with unusual terminal emulators, headless containers — a new CLI argument lets developers force color on or off explicitly.
It’s the kind of change that sounds trivial in a changelog and turns out to matter every time you glance at a terminal window. A red error line catches the eye in a way that a plain-text “ERROR” prefix never will.
A Guardrail for Outdated TypeScript Tooling
Odoo modules increasingly embed JavaScript and TypeScript, especially in the web client and OWL component layers. The language server depends on tsserver— TypeScript’s own analysis engine — to provide accurate completions and diagnostics for those files. But tsserver versions older than 6.0 lack features and fixes that the Odoo Language Server expects, leading to degraded behavior that can look like a bug in the Odoo tooling itself: missing completions, phantom errors, or silent analysis failures.
Rather than letting developers chase those ghosts, version 1.6.2 now checks the installed tsserver version at startup. If it’s older than 6.0, the server surfaces a clear warning with guidance to upgrade. The message appears in the editor’s notification area, not buried in a log file, so developers see it immediately rather than discovering the mismatch after an hour of debugging phantom issues. It’s a simple version gate, but it eliminates a surprisingly common support question.
Paper Muncher Learns to Handle Individual Documents in a Batch
Separately from the language server, Odoo’s PDF generation tool — Paper Muncher — picks up a capability that batch-heavy workflows have been waiting for. When generating multiple PDFs in a single run, every document in the batch previously shared the same header and footer. That’s fine when you’re printing fifty copies of the same invoice template, but it falls apart the moment you need a batch that mixes document types: invoices with one letterhead, delivery slips with another, and packing lists with a third.
Paper Muncher now supports per-document --header and --footeroptions on each input operand. Each document in a batch job can carry its own header and footer templates, and the tool applies them individually during rendering. The syntax stays clean: the existing CLI interface simply accepts the header and footer flags per operand rather than only globally. For companies that generate mixed-format document batches — common in logistics, manufacturing, and multi-brand retail — this removes a workflow that previously required splitting batches into separate runs and stitching the results back together.
Small Fixes, Compound Returns
None of these changes will headline a keynote. A process that now exits when it should, terminal output that uses color, a version check that catches a common misconfiguration, and a CLI flag that saves a post-processing step — taken individually, each one is a minor quality-of-life improvement. But developer tooling occupies a peculiar position in the productivity stack: because developers interact with it hundreds of times a day, even small friction reductions compound dramatically over time.
The zombie process fix alone probably saves a restart or two per week for active Odoo developers. Multiply that across a development team, factor in the time no longer spent squinting at monochrome logs or debugging phantom TypeScript errors, and version 1.6.2 starts to look like one of those releases that nobody notices precisely because everything just works the way it should have all along.