Bossness for VS Code

Bossness turns a user-confirmed Mission into a bounded Codex run. Bossness defaults to a low-friction natural-language flow and supports three explicit endings: complete with an unverified change explanation, run an independent project command, or deliver a read-only report for user review.

Pricing and license

Bossness is free to install and use for personal and commercial work. It is proprietary, closed-source software; see LICENSE.txt. Model-provider access, subscriptions, and usage fees are separate and are not included. Bossness is an independent extension and is not an official OpenAI or Microsoft product.

Prerequisites

• VS Code 1.96 or newer.
• A folder open in VS Code. Git is optional; repository subfolders, dirty worktrees, unborn repositories, detached HEAD, and folders containing multiple repositories are supported.
• A usable Codex app-server. Bossness first uses bossness.codex.executable when configured, then checks the VS Code process PATH, and on macOS finally discovers the Codex bundled with the ChatGPT desktop app. It launches the resolved executable as codex app-server --stdio locally.
• Formal verification is optional. The default No formal verification mode permits bounded workspace changes and finishes with the Worker explanation while keeping achievement NOT_EVALUATED. Select Project command when the outcome needs independent proof, or User-reviewed report for read-only qualitative deliverables. Bossness never converts development feedback or the model's own claim into product acceptance.

The worker and any verification command run locally with the opened workspace as their working directory. New attempts persist a filesystem inventory before execution and compare files against that starting state, including existing edits. Git HEAD and branch are optional descriptive metadata. No automatic commit, stash, initialization, or reset occurs. User-reviewed report Missions receive no workspace write paths; changes during execution in the scanned files still block delivery.

Snapshot inventories are content-addressed and stored in VS Code extension storage outside the workspace. At freeze and acceptance, file bytes are read again, including files unchanged by the Worker. The default scan omits .git, node_modules, .venv, __pycache__, and .cache at every depth. Explicitly named dependency/cache folders in writable paths are included; .git internals always remain excluded. Other .gitignore rules are not applied, so ordinary ignored task files remain visible to change tracking. Symlinks are recorded without following their targets. Exclusions are shown in the composer and delivery limitations. This is a state inventory, not a backup or automatic rollback mechanism; the UI shows changed paths, not a saved line-by-line patch. Concurrent external edits cannot be attributed to the Worker.

Existing attempts and candidates that already contain a Git baseline retain their original Git verification semantics. Missions blocked before an attempt was created can use Recheck and continue to capture a new filesystem baseline. A VS Code multi-root workspace currently uses its first folder; opening a common parent includes its nested repositories.

Build and package

This repository uses pnpm. From this directory:

pnpm install --frozen-lockfile
pnpm verify
pnpm package

pnpm generate:codex refreshes the checked-in Codex app-server compatibility manifest and JSON schema for the installed Codex version. Run it only when intentionally updating protocol compatibility, then rebuild before packaging.

Install

In VS Code, open Extensions, choose Views and More Actions…, select Install from VSIX…, and choose the generated .vsix file.

Alternatively, with the VS Code command-line launcher installed:

code --install-extension bossness-vscode-0.0.20.vsix

Reload VS Code after installation if prompted.

Use

1. Open a folder (including a parent containing several repositories) as the VS Code workspace and open the Bossness activity-bar view.
2. Configure Model settings if needed, then write naturally and choose Start task / 开始任务. This begins read-only Task analysis / 任务分析, followed by an editable confirmation. The default Scope is the current workspace, writable paths are **, and the end mode is No formal verification. The direct-default creation shortcut has been removed; advanced structured input remains available.
3. Review the generated confirmation. Select Revise to open the advanced structured editor for Scope, writable paths, constraints, outcomes, and end mode. The default mode uses one combined confirmation; stricter modes retain the separate capability confirmation.
4. Select Run Mission. Runtime phase, current Worker text, and reported token usage stay visible in the panel; one-shot approval requests are also resolved there. Select Stop execution at any time to interrupt the current model turn or cancel formal verification.
5. If the Mission is blocked, follow the contextual recovery card. Older Git preflight blockers offer Recheck and continue without requiring cleanup; uncertain transport offers reconciliation without resend.
6. After confirmation, the Mission card collapses to a summary so the larger Worker output area gets most of the panel. Use Open in tab for plain text, rendered Markdown, or isolated HTML.
7. After execution, use 报告满足目标 / 接受交付 when formal acceptance is pending, or enter a follow-up below it and choose 继续调整. The acceptance button stays visible outside collapsed delivery details. Bossness analyzes follow-ups with the previous goal and saved report, then asks you to confirm the new Mission. Previous results are attributed context, not authorization or acceptance evidence.
8. The top task selector lists this workspace's saved Missions, groups follow-ups, and supports search. Browsing history does not change or interrupt a running Worker; return to the active task with the banner. Historical output tabs and diagnostics remain bound to the selected Mission. New execution or confirmation on another Mission requires the current run to finish or stop.

Layout follows the current stage: analysis emphasizes the form, confirmation emphasizes the proposal, execution emphasizes output and interruption, blockers emphasize recovery, and delivery emphasizes the report and acceptance/follow-up actions. Previous settings and execution records collapse; manual expansion is retained within the same stage. Help and diagnostics stays at the bottom with local preview/export and optional developer submission. The default developer endpoint is the HTTPS service on 45.76.157.37. Each send requires opt-in, a preview, and Export and send; it is never automatic. The default allowlisted summary excludes task text and runtime payloads; detailed data requires a separate checkbox. The server retains reports for 30 days and emails the approved JSON to the developer's support inbox. See PRIVACY.md for scope and email retention.

The delivery bar shows workflow stages, not estimated time remaining. Token usage defaults to the current execution thread's cumulative total; expand it for input/output, cached-input and reasoning details. Cached input is included in input, and reasoning is included in output, so neither is added twice. These are reported usage statistics, not a budget or remaining quota. Completed tasks display the persisted final Markdown report instead of concatenating intermediate commentary into it.

The panel is the primary interaction surface. These compatibility commands focus the relevant state in that panel:

• Bossness: Start Mission
• Bossness: Run Mission
• Bossness: Open Mission Control
• Bossness: Open Decision Inbox
• Bossness: Open Delivery Review
• Bossness: Export Diagnostics

If Codex cannot be discovered, the blocked-state card explains the problem and offers Select another Codex. The selected executable is stored in the VS Code global setting bossness.codex.executable, so Bossness does not modify the repository.

End modes and verification settings

You can optionally set bossness.verification.command as the default shown in new Mission forms. Use an argv array, not a shell string. For example:

{
  "bossness.verification.command": ["pnpm", "test"],
  "bossness.verification.timeoutMs": 120000
}

Codex drafting uses a dedicated ephemeral read-only app-server thread with no network or effect approvals and a structured output schema. No formal verification is the natural-language default: Candidate scope and digest checks still apply, but the Mission closes as COMPLETED with achievement NOT_EVALUATED and no acceptance prompt or DeliveryManifest. Project command binds the exact confirmed argv and blocks when it is absent or drifts. User-reviewed report has no writable paths, freezes the report bytes, and uses the real user's decision as the final oracle. A recommendation is never authorization; the generated settings are visible in the confirmation.

bossness.runtime.turnTimeoutMs controls the worker-turn deadline and bossness.runtime.pollIntervalMs controls reconciliation polling.

The panel's Model settings controls the highest model, that model's highest reasoning effort, and Luna-based selection. Options come from the current Codex model/list response. For Sol high, Sol may use at most high; lower-tier Luna and Terra may use their full supported effort range (including max/ultra only when listed), while Astra is excluded. This is not a token, spending, or latency cap. Unknown model families are not ranked automatically.

From 0.0.17 there is no routing-only model call before analysis or execution. Luna starts actual read-only task analysis directly at low effort when available, and returns an execution-model recommendation with the proposal. The host validates the recommended pair against the selected ceiling and current catalog, then reuses it only for the matching confirmed brief and policy. The cache holds up to 16 plans. Follow-ups replan during their normal analysis; manual task edits or invalid/unavailable recommendations fall back visibly to the selected configuration without a separate routing wait. Disable adaptive selection to use the selected configuration directly. Existing admitted Attempts keep their recorded model; this is task-boundary planning for one Worker, not per-tool hot swapping or a multi-worker scheduler. bossness.drafting.timeoutMs controls each analysis turn, not the time spent answering clarification questions.

Clarification and execution decisions

Material ambiguity is shown as a panel card with up to three questions, optional choices, and free-text answers. Nothing is selected or submitted automatically. During analysis, answers enter the next typed draft context; no Mission is created until questions are resolved and the resulting proposal is confirmed.

During execution, native item/tool/requestUserInput requests wait for explicit answers. Answers are bound to the active admitted turn and recorded locally before responding; they clarify the current contract but do not authorize scope/permission expansion or delivery acceptance. User wait time is measured separately and excluded from the Worker polling budget. Canceling or losing the live request closes the card rather than inventing an answer.

If the current Codex mode does not expose the question tool, the Worker is instructed to return an explicit bossnessNeedsUserInput JSON envelope. That path blocks before Candidate freeze and displays a persistent card; answers start analysis for a newly confirmed follow-up. It does not silently resume the old Attempt or label the question a finished product. Free-form prose cannot be reliably recognized as a decision; use Continue adjustment for unstructured questions. In-flight native requests are not automatically replayed after an extension-host restart.

Multimodal boundary

From 0.0.20, an explicit empty writable-path list means read-only execution in any verification mode. Read-only questions and follow-ups can use NONE without requiring a final acceptance step. The structured form can leave writable paths blank; confirmation displays “无（只读）”. Missing/malformed model fields still fail validation. Bossness never repairs an empty list by granting **. A follow-up still creates a newly confirmed Mission rather than rewriting the previous authority. Worker start and recovery use the read-only sandbox when the confirmed path list is empty.

From 0.0.19, ＋添加图片 / 文件 also accepts PDF, Word, Excel, PowerPoint, archives and other ordinary files, in addition to PNG/JPEG/WebP and text/code files. You can also paste screenshots or drag files into the panel. Images have thumbnails; text files have snapshot previews. Editing a preview does not alter the pending attachment: remove it and add the replacement. New tasks start without previous attachments; follow-up tasks list inherited attachments for removal or replacement before analysis.

Limits: 4 images, 5 MiB each and 12 MiB total; 8 files, 20 MiB each and 50 MiB total. Small UTF-8 files are inlined up to 128 KiB per file / 256 KiB per request; larger or binary files are provided as verified local snapshot paths, without truncation or binary base64 prompt expansion. A short instruction is still needed alongside attachments.

Images are sent as native image inputs. In both analysis and execution, Codex receives labelled inline text or explicit read-only snapshot paths and uses its available local tools to read documents. Bossness does not implement a PDF/Office parser, add a separate parsing-model call, or guarantee every format is readable. Missing readers, encrypted or corrupt required files must be explained and raised through the user-question flow; optional unreadable references must be disclosed. No automatic dependency installation or external conversion-service upload is authorized. The panel distinguishes saved files from parsed content and shows local-tool activity during analysis. Immutable local copies and digests bind them to confirmation, Capsule and sealed dispatch bytes. Selecting an attachment does not grant write access to its source directory. Explicitly text-only models are rejected before sending images; missing modality fields follow the official legacy text+image default. For questions about attachment support, contact support@vcgpd.com.

Version 0.0.13 also records fixture FIFOs, sockets, and device files as metadata without opening them. If an older diagnostic says Git baseline inspection failed, reload the VS Code window and check the running version in the panel footer. New diagnostics include the embedded runtime build identity and extension path, so stale loaded code can be distinguished from manifest metadata.

M0 limitations

Each run supports exactly one bounded Codex turn. User-initiated follow-ups create a newly confirmed Mission/Attempt carrying the previous goal and full saved result; they do not reopen a frozen Attempt or silently accept its report. The default mode closes with an explicitly unverified explanation; command mode can run one physical formal command; user-review mode freezes one read-only report. M0 does not start an automatic remediation turn. Multi-worker orchestration, multiple verification commands, and automatic repair loops are outside this release.

Durable data and recovery

Bossness stores the mission projection in VS Code workspace state and writes the authoritative append-only JSONL event ledger plus content-addressed exact-byte artifacts under the extension's VS Code storage area. Storage is isolated by a SHA-256 hash of the workspace path. It is not written into the repository.

When Bossness: Run Mission is invoked again, the runtime replays durable records and resumes from the latest completed boundary: it reuses prepared authority and attempt data, reconciles a previously dispatched worker turn when possible, reuses a frozen candidate, or returns an already recorded verification report. Digest-chain and exact-byte checks fail closed if persisted data is truncated, missing, or altered.

Keep VS Code's extension storage if you need recovery or audit continuity. Uninstalling the extension, clearing VS Code application data, changing the workspace path, or opening the same repository through a different path can make prior mission data unavailable. Bossness: Export Diagnostics includes the ledger timeline and governed runtime artifacts, but it is not a restorable backup of the ledger or exact-byte store.

For support, contact support@vcgpd.com. See PRIVACY.md for data handling and LICENSE.txt for usage terms.

Data and connectivity

Bossness starts the configured Codex app-server on the extension host. Developer diagnostic submission is opt-in; there is no automatic analytics uploader. Running Codex can send prompts, source context, and tool results to the model provider configured in Codex; a local process does not mean offline AI. Provider access and any applicable usage charges are separate from this extension.

Mission state, event records, and exact-byte artifacts are stored in VS Code extension storage. Export Diagnostics writes a file to a location you choose; it does not send a support request. Exports can include mission goals, workspace paths, commands, and runtime payloads. Review and redact an export before sharing it.