The repository is not trustworthy: controls for agents at the workspace–runtime boundary.

A code agent receives two things when opening a project: material for understanding and material that can attempt to influence its behavior. Files, local instructions, configurations, dependencies, links, and tool results belong to the same workspace, but do not have the same authority.

This Evidence Brief is based on a batch of nine advisories published by the CodeWhale project on July 16, 2026, and incorporated into the GitHub Advisory Database on September 4. The goal is not to teach how to exploit the flaws nor to evaluate the product by a single batch. It is to derive a technical contract for the boundary between untrusted content, operator policy, and effects produced by the runtime.

Status: Evidence Brief approved for publication on September 7, 2026 at 09:00 BRT. This text does not claim that the proposed controls are implemented or operating in Trustyu Forge.

Factual scope of the case

A CodeWhale advisories page contains nine records published by the maintainer on 07/16/2026 concerning, among other boundaries, project configuration, execution approval, tool arguments, symbolic links, process environment and network access. The corresponding records appeared in GitHub Advisory Database on 09/04/2026.

The correct denominator is nine advisories in that batch. They are not nine incidents, nine active exploitations or nine affected organizations. The project page also lists four previous records, from May; the batch does not represent the entire history.

Severities diverge across surfaces. In the global GitHub database, one record is classified as critical and eight as high. In the repository, the batch appears as one critical, seven high, and one moderate. The difference must remain attributed to each advisory record; it does not alter the shared architectural pattern.

For current packets codewhale-tui and codewhalethe global sheets register versions from 0.8.41 and earlier up to 0.8.64 as affected, indicating 0.8.64 as the first fixed version. Some advisories also register the previous package deepseek-tuiwith their own ranges and correction in 0.8.41. The operational action depends on the package and the version actually installed.

No public evidence of active exploitation, number of affected installations, confirmed incident or financial impact was found up to the cutoff. The project itself published the advisories and remediation references. GitHub, NVD and the maintainer's page reflect the same set of disclosures and should not be counted as independent corroborations.

Trust Model

The minimal design separates four domains:

política do operador ───────────────┐
                                    ↓
repositório não confiável → mediador de capacidade → sandbox/runtime → efeitos
           │                        │                      │              │
           └──── evidência ─────────┴──── receipts ────────┴── auditoria ─┘

1. Operator policy: identity, capabilities, egress, allowed data, and actions requiring approval. It is authority superior to the workspace.
2. Untrustworthy repository: code, configuration, documentation, instructions, and dependencies are inputs. They may request less authority; they cannot grant more.
3. Capability Mediator: validates intent and consequence at the point of action, resolves the actual target, and applies policy centrally.
4. Sandbox/runtime: contains process, filesystem, network, resources and time. Closed failure and produces evidence independent of model text.

Composition error occurs when a layer treats input as authority. A project file may state that tests use a certain command. It should not enable shell. A path may appear internal to the workspace. It should not unilaterally decide the actual destination for reading or writing.

Invariant 1 — configuration is monotonic

Monotonic configuration means that a layer of lower trust can only maintain or reduce the received authority.

capabilities_effective = intersect(
  organization_policy,
  user_policy,
  session_policy,
  repository_restrictions
)

repository_restrictions participates as a restriction, never as a grant. A project can declare “no network” or “read-only”. It cannot change shell=false by shell=truesubstituting a list of user-controlled instructions or adding egress destinations.

O commit associated with the batch apply this principle to a CodeWhale boundary: project overlays may restrict access to shell, but cannot enable it or replace user instruction lists. The commit is evidence of the described correction; it does not prove full audit of the runtime.

Negative tests

• a project requests missing capability and the effective result remains denied;
• a configuration swaps controlled list for local list and loading fails closed;
• the same policy is tested by CLI, interface and automation without alternative path;
• the receipt records the requested policy, the effective policy, and the reason for the difference.

Invariant 2 — approval follows consequence

An action should not be approved merely by tool name or its first call. If an existing session can receive new input, if a process can execute code, or if an equivalent tool produces the same effect, all these paths must pass through the same mediator.

The batch includes records about shell interaction and code evaluation without expected confirmation: GHSA-g29h-pfmp-qp9r and GHSA-wrj3-vj8c-784f.

The approval contract should link:

• identity of the requester and the approver;
• class of effect, not just tool name;
• resolved target and scope;
• normalized arguments;
• validity window;
• digest of the policy and the request;
• executed or blocked result.

An approval should not be valid for “any future command” in a session. Reuse is only safe when the policy explicitly describes the class of effect and the limit that remains valid.

Invariant 3 — confinement uses the actual target

The batch includes advisories about Git tool arguments and link resolution in the workspace: GHSA-c6mw-8xh8-gpq6, GHSA-7j5w-7r7x-9v27 and GHSA-w7wx-5q49-r59w.

Validating the string before execution is insufficient. The mediator must work with typed arguments, resolve the actual destination under an allowed root, and reject changes between validation and use.

A defensive contract includes:

1. API typed by operation, without concatenating text into a generic command;
2. allowlist of flags and parameters per tool;
3. file descriptor or equivalent mechanism bound to the resolved target;
4. reject links or mounts that escape the authorized root;
5. explicit distinction between read, write, create, replace, and execute;
6. log of the logical target and the effective target, without recording sensitive content.

Negative tests

• unknown or ambiguous arguments are rejected;
• a link that resolves outside the root cannot be read or sent to the model;
• the target cannot be swapped between verification and operation;
• read-only operations do not have a collateral write path;
• files outside the scope remain inaccessible even when the process has host access.

Invariant 4 — the environment starts empty

GHSA-h539-c7r8-3xq4 registers exposure of the parent environment to the model context in an execution path. The most robust defense is to build the child process environment from a minimal allowlist.

child_env = {
  runtime_path,
  locale,
  task_scoped_token,
  explicit_non_secret_parameters
}

The token, when indispensable, must be ephemeral, limited by audience, operation, tenant, and time. A secret does not become secure because it was removed from the prompt; if the process or a tool can print it, it can still reach the context.

Negative tests

• non-allowlisted variables do not appear in the child process nor in tool results;
• logs and receipts record capability names, not secret values;
• a task token does not authorize resource, tenant, or operation outside the scope;
• the absence of credentials produces explicit failure, without fallback to operator identity.

Invariant 5 — egress is applied at connection

GHSA-6v2g-fpxh-pmmh describes a time condition related to DNS validation in protection against SSRF. The general standard is not to rely solely on a pre-check of the URL.

An egress layer must:

• resolve names in controlled component;
• block local, private, metadata and disallowed ranges;
• revalidate redirections and effective destination;
• limit protocols, ports, volume, time, and amount of responses;
• prefer service allowlist or dedicated proxy in high-risk tasks;
• log policy decision and sanitized destination.

The goal is not to teach an offensive sequence. It is to ensure that the policy survives differences between requested name, resolved name, and actual connection.

Invariant 6 — instruction does not become authority

GHSA-62f5-cp2p-vq95 and GHSA-gx45-xrj5-g6c4 deal with project configuration influencing instructions or shell access. The harness must preserve provenance and precedence:

The runtime must mark the origin of every instruction and refuse collisions that attempt to promote lower-trust content. The durable harness maintains history, orchestration policy, and execution isolation as explicit boundaries, without transforming model or channel into a security boundary. [HARNESS31-C2]

Minimum Evidence Packet per action

{
  "task_id": "opaque-id",
  "policy_digest": "sha256:...",
  "repository_digest": "sha256:...",
  "requested_capability": "typed-capability",
  "effective_scope": "bounded-scope",
  "approval_ref": null,
  "runtime_identity": "ephemeral-principal",
  "result": "allowed|blocked|failed|inconclusive",
  "artifact_refs": ["immutable-receipt"]
}

The receipt must not contain secrets, unnecessary personal data, or the full repository content. It needs to allow another person to reconstruct which policy was applied to which version and what effect was authorized.

Gate before releasing a code agent

1. Is the repository origin classified?
2. Is the effective policy monotonic and demonstrable?
3. Do shell, filesystem, network, and integrations use an ephemeral and minimal identity?
4. Does every action with equivalent consequence pass through the same mediator?
5. Are paths and arguments resolved and typed before effect?
6. Does the process environment originate from an allowlist?
7. Is egress applied to the effective destination and in each redirection?
8. Do negative tests exercise bypasses of configuration, approval, path, environment, and network?
9. Are failure, blocking, inconclusive, and success distinct states?
10. Does an Evidence Packet link policy, input, action, result, and authority?

Passing this gate only demonstrates the tested scope. It does not prove total security, production readiness, or continuous operation.

Limitations and risk of interpretation

• The set describes a specific product and versions; the proposed architecture is a professional generalization, not a conclusion of the advisories.
• Derived sources repeat the same disclosure and do not measure prevalence or exploitation.
• Severities diverge across surfaces and may change after new review.
• Upgrading to the fixed version is a specific action; adopting all the above controls requires threat model and testing in the organization's environment.
• This brief avoids proof-of-concepts, commands, sensitive targets, and offensive paths.
• No control here is declared as already implemented, tested or operating on the Trustyu Forge.

Direct sources

1. CodeWhale — project advisories.
2. GHSA-6v2g-fpxh-pmmh / CVE-2026-75856.
3. GHSA-g29h-pfmp-qp9r / CVE-2026-75857.
4. GHSA-wrj3-vj8c-784f / CVE-2026-75858.
5. GHSA-62f5-cp2p-vq95 / CVE-2026-75859.
6. GHSA-gx45-xrj5-g6c4 / CVE-2026-75911.
7. GHSA-c6mw-8xh8-gpq6 / CVE-2026-75912.
8. GHSA-7j5w-7r7x-9v27 / CVE-2026-75913.
9. GHSA-w7wx-5q49-r59w / CVE-2026-75914.
10. GHSA-h539-c7r8-3xq4 / CVE-2026-75915.
11. Commit 4356335 — project restricts local overlays.
12. NVD — CVE-2026-75859Disclosure derived, not independent confirmation of exploitation.

Editorial and responsibility note

This text combines facts attributed to public advisories with the author's technical analysis and proposal. Personal and professional viewpoints are not proven facts; data, denominators, limits, and conflicts are indicated when available. It does not constitute an accusation of negligence nor state that there was an incident, exploitation, or damage. The content is informational and does not replace technical, legal, or security assessment. Tech Human and Trustyu operate commercially on related topics. Research, structure, and writing received AI assistance; factual review, author approval, and publication approval were confirmed by Fernando Parreiras on 06/09/2026, without additional independent human review.

Research cutoff: September 6, 2026. Editorial status: special publication authorized for September 7, 2026 at 09:00 BRT.