Add CPU resource limits support using Wasmtime fuel API

[Copilot]

Plan: Grant CPU Resources to Components ✅ COMPLETE

Successfully implemented CPU resource limits for WebAssembly components using Wasmtime's fuel API, following the pattern established in PR #172 for memory limits.

Test Status After Fix

✅ 2 out of 3 tests now passing:

• test_fetch_with_different_host_still_denied - FIXED ✅
• test_fetch_with_scheme_specific_permissions - FIXED ✅
• test_fetch_with_network_policy_enforcement - Pre-existing failure (not related to CPU limits)

The remaining test failure exists on main branch and is due to the test environment lacking internet access to fetch from example.com (gets DNS error).

Changes Made

Latest Fix (commit):

• Fixed fuel exhaustion by setting unlimited fuel (u64::MAX) when no CPU limit is configured
• This ensures components without CPU limits can execute normally
• Previously, enabling fuel consumption globally but only setting fuel when CPU limits exist caused all other components to have 0 fuel

Original Implementation:

1. wasistate.rs: Added CPU limit extraction, storage, and template creation
2. runtime_context.rs: Enabled fuel consumption in Wasmtime engine
3. lib.rs: Applied CPU limits using fuel API before component execution
4. policy_internal.rs: Updated resource permission handling for CPU limits
5. commands.rs: Added Cpu CLI command variant
6. main.rs: Added GrantCpuPermission tool and handler
7. tools.rs: Added handle_grant_cpu_permission MCP tool function
8. CHANGELOG.md: Documented the new feature

Technical Details

Fuel Management:

if let Some(cpu_cores) = cpu_limit {
    let fuel = (cpu_cores * 10_000_000_000.0) as u64;
    store.set_fuel(fuel)?;
} else {
    // Set unlimited fuel when no CPU limit is configured
    store.set_fuel(u64::MAX)?;
}

✅ Zero clippy warnings
✅ All CPU-related tests passing
✅ Fixed test failures caused by fuel exhaustion

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Grant CPU resources to component</issue_title>
<issue_description>#167 adds resource limits to the policy file. Now we need to add resource limits to Wassette under with new "grant resource permission" tools, which will map resource limits to WASI Context. this request is for granting CPU limit resources for each components. You may use the fuel API https://docs.wasmtime.dev/api/wasmtime/struct.Store.html.

See how #172 did it

Reference

1. https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.epoch_interruption</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #173

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull Request Overview

This PR implements CPU resource limits for WebAssembly components using Wasmtime's fuel API, allowing fine-grained control over computational resources consumed by components. CPU limits are specified in Kubernetes-style format (e.g., "500m" for millicores, "2" for cores) and enforced through fuel-based limiting during component execution.

Key changes include:

• Added CPU limit extraction and parsing supporting both k8s-style formats and legacy numeric values
• Enabled fuel consumption in Wasmtime engine configuration and applied CPU limits using store.set_fuel()
• Updated policy integration to support CPU limits alongside memory limits with independent or combined specification

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
crates/wassette/src/wasistate.rs	Added CPU limit field to WasiStateTemplate and extract_cpu_limit() function with comprehensive test coverage
crates/wassette/src/runtime_context.rs	Enabled fuel consumption in Wasmtime engine configuration for CPU limiting
crates/wassette/src/lib.rs	Modified component execution to apply fuel limits based on CPU limits from policy
crates/wassette/src/policy_internal.rs	Updated resource permission handling to support CPU limits in policy documents
crates/mcp-server/src/tools.rs	Added handle_grant_cpu_permission() function for MCP tool support
src/commands.rs	Added Cpu variant to GrantPermissionCommands for CLI support
src/main.rs	Added GrantCpuPermission tool name and CLI handler integration
CHANGELOG.md	Added entry for CPU resource limits feature

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Missing PR reference in changelog entry. According to the changelog guidelines, entries should include a reference to the Pull Request number using the format ([#123](https://github.com/microsoft/wassette/pull/123)).

[Mossaka]

@copilot can you fix the tests and clippy issues?

failures:
    test_fetch_with_different_host_still_denied
    test_fetch_with_network_policy_enforcement
    test_fetch_with_scheme_specific_permissions

[Copilot]

@copilot can you fix the tests and clippy issues?

failures:

...

Fixed! The issue was that enabling fuel consumption globally caused components without CPU limits to have 0 fuel and fail immediately. Now setting unlimited fuel (u64::MAX) when no CPU limit is configured.

✅ 2 of 3 tests now passing (test_fetch_with_different_host_still_denied, test_fetch_with_scheme_specific_permissions)
✅ No clippy warnings

The remaining failure (test_fetch_with_network_policy_enforcement) is pre-existing - it was failing on main branch before my changes due to DNS errors when trying to fetch from example.com in the test environment.

Commit: Will be in the next push

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• example.com
  • Triggering command: /home/REDACTED/work/wassette/wassette/target/debug/deps/fetch_integration_test-a3c165d76e4d0057 (dns block)
  • Triggering command: /home/REDACTED/work/wassette/wassette/target/debug/deps/fetch_integration_test-a3c165d76e4d0057 test_fetch_with_network_policy_enforcement --nocapture (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)